Choose a value for build name

This page relates to Record builds from multiple repositories.

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:

Table 1. System-specific build name values
CI system	Suggested <BUILD NAME> value	Documentation
Azure DevOps Pipelines	`Build.BuildId`	Azure DevOps Pipelines variables
Bitbucket Pipelines	`BITBUCKET_BUILD_NUMBER`	Bitbucket Pipelines variables
CircleCI	`CIRCLE_BUILD_NUM`	CircleCI environment variables
GitHub Actions	`GITHUB_RUN_ID`	GitHub Actions environment variables
GitLab CI	`CI_JOB_ID`	GitLab CI predefined variables
GoCD	`GO_PIPELINE_LABEL`	GoCD environment variables
Jenkins	`BUILD_TAG`	Jenkins
Travis CI	`TRAVIS_BUILD_NUMBER`	Travis CI environment variables

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}}" .

CloudBees Smart Tests discourages using a Git commit hash (or the output of git-describe ) if there is only one source code repository.

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