Choosing a value for <BUILD NAME>

Your CI process probably already relies on some identifier to distinguish different builds. Such an identifier might be called a build number, build ID, etc. Most CI systems automatically make these values available via built-in environment variables. This makes it easy to pass this value into record build:

CI system

Suggested <BUILD NAME>

Docs

Azure DevOps Pipelines

Build.BuildId

Link

Bitbucket Pipelines

BITBUCKET_BUILD_NUMBER

Link

CircleCI

CIRCLE_BUILD_NUM

Link

GitHub Actions

GITHUB_RUN_ID

Link

GitLab CI

CI_JOB_ID

Link

GoCD

GO_PIPELINE_LABEL

Link

Jenkins

BUILD_TAG

Link

Travis CI

TRAVIS_BUILD_NUMBER

Link

Other examples:

  • If your build produces an artifact or file that is later retrieved for testing, then sha1sum of the file would be a good build name as it is unique.

  • If you are building a Docker image, its content hash can be used as the unique identifier of a build: docker inspect -f "{{.Id}}".

If you only have one source code repository, it might tempting to use a Git commit hash (or git-describe) as the build name, but we discourage this.

It's not uncommon for teams to produce multiple builds from the same commit that are still considered different builds.