Please take a look at the "first basic rule" in our RB Hints for Developers, Konrad: always build the release APK from a clean tree at the commit the tag points to – the current one was built from 4 commits later. One of the easiest ways to break RB (and the most frequent cause of extra work on our side to get stuff fixed 🙈 )…
Unfortunately, building from 454b3bd (the commit hash the APK provided) is only getting close – versionCode differs by 1. So you had the version bump already done locally, but only included that 2 commits later; would I build from there, the strings changed with the commit in between would have let RB fail.
So I had to apply some dirty tricks to fix this one:
- git checkout 454b3bd2dbb0f907cb2dcadadd93049ab67d5fdb
- sed -ri 's/versionCode 26031506/versionCode 26031507/' app/build.gradle
- ./gradlew assembleRelease
and need to clean that up with the next release (so manual action again, instead of an "automated build" 😢 )
Thanks for your attention to this mat… err… 🙈 for taking care 😉
Please take a look at the "first basic rule" in our RB Hints for Developers, Konrad: always build the release APK from a clean tree at the commit the tag points to – the current one was built from 4 commits later. One of the easiest ways to break RB (and the most frequent cause of extra work on our side to get stuff fixed 🙈 )…
Unfortunately, building from 454b3bd (the commit hash the APK provided) is only getting close –
versionCodediffers by 1. So you had the version bump already done locally, but only included that 2 commits later; would I build from there, the strings changed with the commit in between would have let RB fail.So I had to apply some dirty tricks to fix this one:
and need to clean that up with the next release (so manual action again, instead of an "automated build" 😢 )
Thanks for your attention to this mat… err… 🙈 for taking care 😉