How are people solving the somewhat tedious proble...

# random

[darkmoon_uk]

How are people solving the somewhat tedious problem of incrementing Android App Version Codes for their CI release builds?

Having looked at several options I'm thinking of keeping a simple 'counter file' outside the Git repo, and have runners read, increment and write it via scp. A crude solution maybe, but simple, in fact so simple that if it ever got out of step it'd be very easy to fix (just edit the number in the file manually).

Even Fastlane doesn't really solve this problem, it has an increment plugin but this only increments 'once' unless you also commit the value back to the repo: and a CI runner committing changes seems very undesirable to me for several reasons.

Using branch build count could work nicely but the CI I'm using (GitLab) doesn't track this.

[Jurriaan Mous]

Maybe a silly idea depending on the type of project and team. You could use a second based unix timestamp if it is very unlikely you publish on the same second. Maybe substract 1600000000 so you dont run out of codes in the year 2036 but more like 2086. ( Max Android version code is 2100000000) Very likely by then they allow either bigger codes or Android has been superseded by a different OS.

[james]

we do something really basic that is robust enough for us:
git rev-list --count HEAD

this gives us the total count of commits on the current branch, and we have configured our build script to use that count as the versionCode

this way there is no incrementing/writing/updating any file or counter somewhere, since it’s just based on the repo itself

if our repo ever changes dramatically (ie. lost history, or repo split/merge or something) we can simply add a million or so to the count inside the build script and continue on our way