Skip to content

WIP: add sensible defaults to the build metadata

Hans-Christoph Steiner requested to merge eighthave/fdroidserver:build-tools-features into master

This adds a new AutoUpdateMode: to base updates purely on git tags. This also makes Builds: entries optional. If an app has git release tags and works with the defaults, then no Builds: entries would be needed. This does not mean that have to leave out the Builds: entries. They can still be added and everything will work as before.

Most of the time, each entry in Builds: is the same exact thing as the previous, minus versionCode/versionName/commit diffs. So if commit is auto-defined as the git tag and versionCode/versionName is optional #387 (closed), then most build entries are purely redundant. They do provide a permanent record of releases that were tried, e.g. if upstream deletes tags. The archived APKs, source tarballs, and build logs also provide that info.

Defaults:

  • WebSite: based on SourceCode: or Repo:
  • SourceCode: based on Repo:
  • IssueTracker: based on Repo: if it is github or gitlab
  • commit: defaults to one per git tag
  • gradle: yes is build.gradle is present at the root
  • commit: versionName if commit: is not set
  • subdir: app if it is a gradle build and app/ is present
  • read versionName and versionCode from APK if left blank

These are the only other uses of Builds: entries that I could find:

  • fdroid update only uses limited bits of the Builds: entries. When generating the index, fdroid update only checks the builds for a versionName if the versionName can't be parsed from the APK. That code can already handle if versionName is not in the metadata file's build entry.
  • If someone needs to disable one APK, then a Builds: entry is required. update.delete_disabled_builds() needs versionCode so it can generate the filename to delete.
  • fdroid update will read antifeatures from Builds: entries if they are present, then include that in the index. So setting a per-APK anti-feature different from the previous APK will require a new build entry.
  • Flavour-specific fastlane/tripleT files already look for the gradle flavour in the most recent Builds: entry, so only one entry is needed to support gradle flavours.
  • fdroid lint already handles missing build.commit, and doesn't use build.subdir or build.gradle. versionName/versionCode need to be handled

More discussion here in #fdroid: https://matrix.to/#/!HwocBmCtBcHQhILtYQ:matrix.org/$1542381676609448UANNL:matrix.org

Edited by Hans-Christoph Steiner

Merge request reports