Cirrus-ci-docs: Monotonically increasing CI_BUILD_NUMBER

[dotdoom]

Multiple CIs already offer monotonically increasing build number, which is an extremely useful (if not vital) source of build ID for mobile applications (both App Store and Play Store require each subsequent release to have this number increased).

Indeed, workarounds like counting the number of tags or commits may be used as such an indicator; however, if a deployment breaks on a commit due to external reasons, the subsequent deployment attempt on the same commit will fail.

In addition, some popular services like Coveralls and Codecov require a Build Number to be available for coverage reports within CI to be uploaded successfully.

Looks like Cirrus CI does not support build number right now (CIRRUS_BUILD_ID does not seem to be a number). Is this something that may be added in future?

[fkorotkov]

CIRRUS_BUILD_ID is certainly not increasing but it can be used with the coverage tools you mentioned. CIRRUS_BUILD_ID is globally unique within all builds on Cirrus.

Having CI_BUILD_NUMBER totally makes sense. The only issue with it might be that sometimes you can have a race condition when two commits A and then B got merged into master but webhooks are deliver out of order. In this case logically commit number A should be smaller then for B but it's impossible to achieve in this race condition.

Can you for example use commit timestamp in the mean time as a build number for releases?

[RDIL]

+1 for numbered build ids like 345, this would help as right now the ID fails my CI buildmbecause it is too long.

[dotdoom]

Thanks, I agree that using commit timestamp as an indicator is a good alternative, however this workaround has the same problem as counting the number of commits. In particular, it does not solve the issue in these rebuild scenarios (based on real events):

Scenario 1

• CI builds the project and deploys to Play Store but App Store deployment fails (transient issue)
• operator re-runs CI build, but latest commit timestamp is the same, and now deploy to Play Store fails

Scanario 2

• CI builds the project and deploys to a Store
• a critical error has been introduced and a rollback is necessary. Crafting a revert commit, waiting for all approvers and CI checks to pass will take time. Instead, the operator clicks rebuild button on a known-to-be-good build, but CI fails to deploy because the build number is less than the latest

---

Regarding the race condition, I wouldn't attribute webhook call sequence to CI build numbers. After all, we call it build number, as opposed to commit number.

[dotdoom]

Here's a way to abuse GraphQL API to get the number:

  print_build_number_script:
  - export CI_BUILD_NUMBER=$(curl -sSL 'https://api.cirrus-ci.com/graphql'
      --data-binary '{"query":"
      query GitHubRepositoryQuery {
        githubRepository(
          owner:\"'$CIRRUS_REPO_OWNER'\",
          name:\"'$CIRRUS_REPO_NAME'\"
        ) {
          builds(last:102400) { edges { node { id } } }
        }
      }
    "}' | grep -o id | wc -l)
  - echo $CI_BUILD_NUMBER

Indeed, it is prone to almost every race condition possible, and API endpoint should not be used without a generated access token.

I'm sorry.

[RDIL]

can we not resort to abuse

[fkorotkov]

@dotdoom what if Cirrus will expose GitHub Check ID? It seems to be globally unique and monotonically increasing.

[dotdoom]

@fkorotkov that's an interesting idea, particularly appealing because of the reuse of an existing ID. I couldn't find any documentation about that ID, although it is seemingly present in all the sample payloads.

While not a big fan of relying on undocumented features,

I am ready to use what we get if it's proxied through Cirrus CI platform and added into Cirrus CI documentation.

And since we're already here, having that build ID exposed on Web UI would be fantastic for debugging purposes!

[dotdoom]

One thing I was thinking about is a situation where the schema for those IDs changes suddenly and the value jumps to a very large number. We bake this number into the app during build, and it is later exposed to a distribution platform. Such jump is undesirable for multiple reasons: Play and App Store platforms have a requirement of ever increasing build number; large numbers are harder to pass around between developers, or to compare visually etc.

However, our build does not directly publish the app - it merely uploads the binary for verification. So I think we can recover from such situation by removing the malformed app from the distribution platform before it is published, thus circumventing the requirement.

I have no idea what happens if the number jumps to something like MAX_INT-1. Would it leave us with just a single release in the app lifetime? This is a highly unlikely scenario, and may be interesting only for academic reasons.

[fkorotkov]

BTW why don't you use tags and releases for that purpose then? Do you release each commit?

[dotdoom]

We do release each merge into master. This allows us to shorten the release cycle and feedback loop (see this nice presentation from Flickr in 2009. Modern distribution platforms and tools for end to end testing allow for considering Mobile apps almost like Web apps). The build takes major.minor from the latest tag and updates patch version (semver vocabulary). It goes into Internal track for testing (TestFlight for Apple), which also takes a while because of unavoidable security tests on the distribution platform. When we've manually verified that the release is good, we promote it to our Beta testers. If we're especially excited to release a build, such as adding a new feature, we give it a bump on "minor" version number by pushing a tag, and then release to Production.

If we don't feel like promoting a particular build, we left it hanging in Internal until superseded by the next one, but it's very handy to be a click away from pushing forward, without the manual process of dealing with tags and rebuilds. And after that, sitting around until distribution platforms finish their secretsauce tests of the freshly baked upload and enable the "move forward" button.

[fkorotkov]

GITHUB_CHECK_SUITE_ID is now available as a workaround. While re-reading this I realized what you actually want, you want this number for tasks and not builds since you want a re-run of a deploy to have an incremented number. Created #305 to track that.