Choosing a value for build name

1 minute read

This page relates to Recording 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 :

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.
Introduction
Recording builds from multiple repositories