fix(ado-pipelines): correct counter() to compile-time $(...) syntax - #22
Merged
Conversation
The Build Versioning section (§13.2) used runtime-expression syntax $[counter(...)] for the pipeline run identifier. The counter() function in the name/Build.BuildNumber field is a compile-time expression and must use $(counter(...)); the $[...] form is only valid for runtime expressions in task bodies and is not evaluated when the name field is set at queue time. This correction was intended for PR #14 but was accidentally pushed to a detached branch rather than the PR, so it never merged. This lands it on main. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the Azure DevOps pipeline build versioning guidance in standards/ado-pipelines.md, specifically the recommended counter() syntax used when describing name: / Build.BuildNumber queue-time evaluation.
Changes:
- Replaced the documented
counter()syntax in the “Automated versioning” guidance ($[counter(...)]→$(counter(...))).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| | Incompatible breaking change | Remove existing endpoint | `1.3.0 → 2.0.0` | | ||
|
|
||
| **Automated versioning.** Separate the two mechanisms. For the run identifier, prefer an automated source — `$[counter(...)]` for a monotonic build counter, or GitVersion where richer version derivation is needed — so `Build.BuildNumber` needs no manual maintenance. Reserve manual SemVer maintenance for the declared release/version variable (§13.1), where the MAJOR/MINOR/PATCH decision reflects a deliberate human judgement about the nature of the change that no counter can infer. | ||
| **Automated versioning.** Separate the two mechanisms. For the run identifier, prefer an automated source — `$(counter(...))` for a monotonic build counter, or GitVersion where richer version derivation is needed — so `Build.BuildNumber` needs no manual maintenance. Reserve manual SemVer maintenance for the declared release/version variable (§13.1), where the MAJOR/MINOR/PATCH decision reflects a deliberate human judgement about the nature of the change that no counter can infer. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Corrects the Azure DevOps
counter()expression syntax in the Build Versioning section (§13.2) ofstandards/ado-pipelines.md.The text recommended
$[counter(...)](runtime-expression syntax) for the pipeline run identifier. Thecounter()function used in thename/Build.BuildNumberfield is a compile-time expression and must use$(counter(...)). The$[...]form is only valid for runtime expressions inside task bodies and is not evaluated when thenamefield is set at queue time — so the documented form would not work.Why a separate PR
This one-line correction was intended for #14 but was accidentally pushed to a detached
semverbranch rather than the PR's fork branch, so it never merged.mainstill carried the buggy form. This PR lands the fix.Change
$[counter(...)]→$(counter(...))(single line).