Choosing a value for <BUILD NAME>
This page relates to Recording builds.
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> value
Documentation
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 the sha1sum of the file itself 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 the output of 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.
Copy link