Reproducible Build fails for v2.5.9

[IzzySoft]

Could it be that latest-version.yaml is out of sync?

     XML ELEM START [lineno=2, name='manifest', #attributes=7]
-      ATTR: http://schemas.android.com/apk/res/android:versionCode=420509001
+      ATTR: http://schemas.android.com/apk/res/android:versionCode=420509000
       ATTR: http://schemas.android.com/apk/res/android:versionName='2.5.9'

off-by-one. Same then in DEX:

 |: const-string v0, "User-Agent"
-|: const-string v8, "Owntracks-Android/oss/420509001"
+|: const-string v8, "Owntracks-Android/oss/420509000"
 |: invoke-virtual {v2, v0, v8}, Lokhttp3/Request$Builder;.header:(Ljava/lang/String;Ljava/lang/String;)V

plus a couple more differences. Now, even if we adjust that in latest-version.yaml by increasing it by one, that seems to be ignored: I see the very same sha256sums for our builds as before. In your GHA I see you now use fastlane to evaluate versionCode – but I see it nowhere taken from nor written to the version file.

So is the VERSION_CODE environment variable still honored? Where can we take it from? The values in latest-version.yaml seem way of:

versionName: 2.5.7
versionCode: 420507014

I see there's logic in your build.gradle to calculate versionCode – but I don't see how that could end up in 420509001, unless "manually" overridden by the environment variable – which in our build, didn't seem to have any effect (aaaargh! because the one we ended up with from latest-version.yaml was lower). Gnaa… Sorry, but this way we cannot reach RB – we need to have the same settings. If you override things manually, we'd need to do the same, which cannot be automated.

So can we agree upon release builds NOT having any "manual overrides"? Especially with "flaky builds" like here (where 10 builds in a row produce 2 or more different APKs), such things are hard to track down. This one took me more than an hour now – and it was not the only failed build today 😢

OK, finally succeeded by explicitly exporting the VERSION_CODE you used. That means, the next release again needs adjustments (at least if you again manually override)…

[growse]

Yeah, latest-version hasn't been bumped yet, just because there's been a lot of release flux. I've just pushed an update to latest-version.yaml, although I should figure out a way to automate updating latest-version.yaml when there's a tag (with the right build code).

The release apk has the correct build version in too:

$ /home/growse/Android/Sdk/build-tools/34.0.0/aapt dump badging owntracks-release-oss-420509001.apk
package: name='org.owntracks.android' versionCode='420509001' versionName='2.5.9' platformBuildVersionName='16' platformBuildVersionCode='36' compileSdkVersion='36' compileSdkVersionCodename='16'

I see there's logic in your build.gradle to calculate versionCode – but I don't see how that could end up in 420509001, unless "manually" overridden by the environment variable – which in our build, didn't seem to have any effect (aaaargh! because the one we ended up with from latest-version.yaml was lower). Gnaa… Sorry, but this way we cannot reach RB – we need to have the same settings. If you override things manually, we'd need to do the same, which cannot be automated.

The way that version codes work is thus:

• There's a baseline versioncode calculated from the version name. This is the generateVersionCode function
• On CI, every time there's a build on master it fetches the current version code of the google play store internal track. In then sets VERSION_CODE to be max(play_code + 1, generatedVersionCode). This means we get incremental build numbers on trunk builds, but also they increment from a code that's got some relationship with the version name.
• Releases don't rebuild, they just promote the apk on google play. So if the trunk build that builds version "x" is good enough for beta and release, "x" is the version code of the release.
• The awkward hack is that on release, we generate a new APK for the github release (both flavours) and manually set VERSION_CODE during the build to whatever-we-just-promoted-on-google-play. That way, what people see when they pull the apk from gh releases and what they see in the app installed off google play is the same version code.

It's not great, but it meets one of my main requirements which is 1) promote builds from testing tracks and 2) I don't want to commit a file on every build just to set a new version number. The downside is that I have to (currently) remember to update latest-version.yaml on releases so that fdroid / others can build against the right version / code.

Does the updated latest-version.yaml fix your current issue?

[IzzySoft]

Does the updated latest-version.yaml fix your current issue?

I can tell that after the next release. If, at the tagged commit, that file has the correct values, it would fix the issue, yes. With about 900 apps in our main builder, we cannot adjust each one manually. Fixing broken builds already takes multiple hours on some days 🙈 (yes, maintenance at IzzyOnDroid has become a full-time job – unfortunately, an unpaid one; needs to be seen how long I can keep that level up. At one point, I might simply have to pass failed ones as failed, instead of making detailed reports as I currently do…)

[growse]

Gotcha. I'll work on getting a way to have the right version code into the latest-release.yaml on tag to help make life easier.