Versioning pipeline artifacts
Design a versioning strategy for pipeline artifacts
An artifact version must let you answer, months later: which commit produced this, and which run?
Run numbers
name: $(Date:yyyyMMdd)$(Rev:.r)name sets the run number (Build.BuildNumber). $(Rev:.r) is the auto-incrementing counter that resets when the rest of the name changes — which is how you get 20260805.1, 20260805.2 within a day.
Available tokens include $(Date:...), $(Rev:.r), $(BuildID), $(SourceBranchName). Note Build.BuildId is a globally unique integer while Build.BuildNumber is the formatted name — they are not the same and are easily confused.
What a good scheme carries
| Element | Why |
|---|---|
| Commit SHA | The only unambiguous link back to source |
| Semantic or calendar version | Human meaning |
| Run identity | Links to logs, test results, approvals |
Embedding the SHA is the non-negotiable part. A version like 2.4.1 alone cannot tell you which of three rebuilds produced the binary in production.
Immutability
Publish once, promote thereafter. Rebuilding to produce "the same" version breaks traceability just as surely as re-pushing a container tag — which is why build once, deploy many and artifact versioning are really the same discipline seen from two angles.
Primary sources