Best Practices for when to generate a Git Tag using this plugin and CI/CD

[TylerMcCraw]

I'd be interested in hearing your thoughts on best practices for how/when you create a Git Tag when also using CI/CD for builds. I've run into some curiosities when using the plugin with our CI environment.

For instance, the version code may start out as 1.2.3 on my development branch. If my override function computes this versionCode as: semVer.major * 10000 + semVer.minor * 100 + semVer.patch + gitTag.commitsSinceLatestTag then this will produce a versionCode as: 10203

Now, let's say I've committed 7 times since the creation of the Git Tag and I want CI to run tests and deploy an internal/beta build. This means that the newest versionCode will now be: 10203 + 7 == 10210

When I create a PR pointed from development branch to master and CI generates a production/Play Store build the gitTag.commitsSinceLatestTag is going to return 0. This means that the versionCode is going to be lower than the latest development build: 10203 + 0 == 10203

This is problematic because we want our builds to always be incremental. I would have expected the version code for the Play Store release to be 10210 or higher.

I feel like either I create the Git Tag on the wrong branch which causes commitsSinceLatestTag to return 0 or I'm not understanding the best practice for generating a version code. Any help is much appreciated.

Currently, I am working around this by using a different function for generating the version code: This simply computes number of commits by using a git command to count the number of revisions since the latest major version tag.

    overrideVersionCode { gitTag, _ ->
        def semVer = SemVer.fromGitTag(gitTag)
        def majorVersion = semVer.major.toString()
        def commitsSinceLastTag = ['sh', '-c', "git rev-list $majorVersion.0.0..HEAD --count"].execute().text.trim().toInteger()
        semVer.major * 10000 + commitsSinceLastTag
    }

[ychescale9]

When I create a PR pointed from development branch to master and CI generates a production/Play Store build the gitTag.commitsSinceLatestTag is going to return 0.

I'm trying to figure out why this would become 0 after merging to master. Do you recreate / move the 1.2.3 tag after your merge?

I don't think It matters on which branch you create the tag, if you do a "fast-forward" when merging development to master, any new tags pointing to the new commits since the previous merge will just be carried over so commitsSinceLatestTag should not be reset to 0.

But I feel like I'm not fully understanding your release process, specifically when you create a tag for the new release?

As to "best practices", I think it depends on your development and release process and I don't want the plugin to dictate or even influence your process. A few things I would consider:

• Adding new tag to the specific commit that generates the final APK that gets pushed to production (this implies commitsSinceLatestTag being 0 for the build that gets pushed to production, although it means if you found some issue after pushing internal test track but before rollout, you'll have to bump the PATCH version to make sure the generated versionCode is incremental)
• using separate applicationId for internal / beta builds - the internal build's versionCode and versionName are generated from the previous tag (e.g. 1.2.3) plus the number of commits since that tag e.g. 7.
• Trigger the CI build that deploys the release APK to playstore when a new tag is pushed.

On the plugin side I had some ideas around tag filtering but I'm not sure how / whether it's going to cover enough use cases to be worth doing.

One thing I'm considering though is adding a buildVariant parameter to the overrideVersionCode and overrideVersionName lambdas so you can customize based on your build variants. Do you think that'd be something useful?