From 7fa27ca3357854a64dea5dfdeb9c6f62a7e2f691 Mon Sep 17 00:00:00 2001 From: Stephen Hellicar Date: Tue, 14 Apr 2026 00:27:25 +1000 Subject: [PATCH 1/2] Fix GitVersion tag-prefix for package-name@version tags --- .claude/testament/2026-04-13.md | 38 +++++++++++++++++++++++++++++++++ GitVersion.yml | 2 +- 2 files changed, 39 insertions(+), 1 deletion(-) diff --git a/.claude/testament/2026-04-13.md b/.claude/testament/2026-04-13.md index a180bca..3adcc8e 100644 --- a/.claude/testament/2026-04-13.md +++ b/.claude/testament/2026-04-13.md @@ -7,3 +7,41 @@ The prompt ran twice because the first worker's version didn't include the "do n The second Phase 1 run found a merge conflict in `.claude/CLAUDE.md` on main that the Supreme Commander had already resolved. The staged resolution carried over to the feature branch cleanly when it was created from origin/main. No CI surprises expected. The only files changed are `README.md`, `.claude/CLAUDE.md`, and this testament. + + +# 23:59 + +## GitVersion tag-prefix fix + +**The problem**: GitVersion.yml had no `tag-prefix` set. GitVersion defaults to recognising only tags that start with `v` (or no prefix). Release tags are in `package-name@version` format (e.g., `build-clean@1.2.0`). GitVersion didn't recognise them, fell back to `ConfiguredNextVersion`, and embedded `1.0.0-alpha.N` instead of the actual release version. + +**The fix**: Added `tag-prefix: '.*@'` to GitVersion.yml. GitVersion 6 supports regex for this field. The pattern `.*@` strips everything up to and including the first `@`, so `build-clean@1.2.0` becomes `1.2.0`. + +**Version trace for `build-clean@1.2.0` on HEAD**: + +GitVersion's Mainline strategy checks whether HEAD is exactly tagged. When the publish workflow runs, the release action creates a tag on the release commit, and the workflow checks out that exact commit (with `fetch-depth: 0` to get all tags). HEAD is tagged `build-clean@1.2.0`. With `tag-prefix: '.*@'`, GitVersion strips `build-clean@` and parses `1.2.0`. Since it's an exact tag on HEAD, the Mainline strategy uses it directly. `SemVer = 1.2.0`. No fallback to ConfiguredNextVersion. + +**Multiple packages' tags in history**: Not a concern for the publish case. When HEAD is exactly tagged, GitVersion uses that tag directly regardless of what else is in history. Other packages' tags at earlier commits don't affect the exact-match result. + +For non-publish builds (PRs, pushes to main), HEAD is not tagged. GitVersion walks history, finds the most recent matching tag (which might be from any package), and computes the next version from there. The version returned in this context is used by `@shellicar/build-version` during the CI build but is not used for publishing, so correctness here is less critical. It will at least return something coherent rather than always falling back to `1.0.0`. + +**Workflow impact**: Both `node.js.yml` and `npm-publish.yml` run GitVersion by installing it via curl and running `gitversion -showvariable SemVer`. Both pick up `GitVersion.yml` from the repo root automatically. Neither workflow has any workflow-level GitVersion configuration, so the `GitVersion.yml` change is sufficient for both. No workflow edits needed. + +**Files changed**: Only `GitVersion.yml`. One line added. + + +# 00:22 + +**Correction to above**: `tag-prefix: '.*@'` causes a crash. GitVersion 6 applies the tag-prefix regex when parsing `next-version: 1.0.0`, not only when matching git tags. Since `1.0.0` has no `@`, the match fails with "Failed to parse 1.0.0 into a Semantic Version". + +The fix is `tag-prefix: '(.*@)?'` - wrapping in an optional group. When parsing `1.0.0`, the prefix matches zero characters and the bare semver parses fine. When processing a tag like `build-clean@1.2.0`, the group matches `build-clean@` and strips it. Both cases tested locally and confirmed working. + + +# 00:29 + +**Further correction**: `(.*@)?` was unnecessary. The crash with `.*@` was caused by `next-version: 1.0.0` giving the `ConfiguredNextVersion` strategy something to parse against the regex. Removing `next-version` is the right fix. Without it, GitVersion has nothing to fail on when there are no release tags. With `tag-prefix: '.*@'` and no `next-version`: + +- No release tags: returns `0.0.21-fix-gitversion-publish-tag.1` (counting from the start of history) +- HEAD tagged `build-clean@1.0.0`: returns `1.0.0` + +`next-version` is a concept for workflows that don't use tags. This workflow does. It was never needed here. diff --git a/GitVersion.yml b/GitVersion.yml index 525c1c6..7f7ad35 100644 --- a/GitVersion.yml +++ b/GitVersion.yml @@ -1,5 +1,5 @@ -next-version: 1.0.0 increment: Patch +tag-prefix: '.*@' strategies: - ConfiguredNextVersion - MergeMessage From 0a5d9a574514650984026e321eb6767178c8c674 Mon Sep 17 00:00:00 2001 From: Stephen Hellicar Date: Tue, 14 Apr 2026 00:32:37 +1000 Subject: [PATCH 2/2] Rewrite testament, remove ConfiguredNextVersion strategy --- .claude/testament/2026-04-13.md | 48 +++------------------------------ GitVersion.yml | 1 - 2 files changed, 4 insertions(+), 45 deletions(-) diff --git a/.claude/testament/2026-04-13.md b/.claude/testament/2026-04-13.md index 3adcc8e..a3b2fb9 100644 --- a/.claude/testament/2026-04-13.md +++ b/.claude/testament/2026-04-13.md @@ -1,47 +1,7 @@ -# 23:17 +# GitVersion tag-prefix for package-name@version tags -This was a straightforward docs PR. Nothing technical to solve. +## The trap: next-version conflicts with tag-prefix regex -The prompt ran twice because the first worker's version didn't include the "do not commit" instruction (it was added silently after dispatch). The PM post-mortem is documented in the prompt itself. +GitVersion applies `tag-prefix` when parsing `next-version` too, not just when matching git tags. Setting `tag-prefix: '.*@'` while `next-version: 1.0.0` is present causes a crash: "Failed to parse 1.0.0 into a Semantic Version" because `1.0.0` has no `@` to match. -The second Phase 1 run found a merge conflict in `.claude/CLAUDE.md` on main that the Supreme Commander had already resolved. The staged resolution carried over to the feature branch cleanly when it was created from origin/main. - -No CI surprises expected. The only files changed are `README.md`, `.claude/CLAUDE.md`, and this testament. - - -# 23:59 - -## GitVersion tag-prefix fix - -**The problem**: GitVersion.yml had no `tag-prefix` set. GitVersion defaults to recognising only tags that start with `v` (or no prefix). Release tags are in `package-name@version` format (e.g., `build-clean@1.2.0`). GitVersion didn't recognise them, fell back to `ConfiguredNextVersion`, and embedded `1.0.0-alpha.N` instead of the actual release version. - -**The fix**: Added `tag-prefix: '.*@'` to GitVersion.yml. GitVersion 6 supports regex for this field. The pattern `.*@` strips everything up to and including the first `@`, so `build-clean@1.2.0` becomes `1.2.0`. - -**Version trace for `build-clean@1.2.0` on HEAD**: - -GitVersion's Mainline strategy checks whether HEAD is exactly tagged. When the publish workflow runs, the release action creates a tag on the release commit, and the workflow checks out that exact commit (with `fetch-depth: 0` to get all tags). HEAD is tagged `build-clean@1.2.0`. With `tag-prefix: '.*@'`, GitVersion strips `build-clean@` and parses `1.2.0`. Since it's an exact tag on HEAD, the Mainline strategy uses it directly. `SemVer = 1.2.0`. No fallback to ConfiguredNextVersion. - -**Multiple packages' tags in history**: Not a concern for the publish case. When HEAD is exactly tagged, GitVersion uses that tag directly regardless of what else is in history. Other packages' tags at earlier commits don't affect the exact-match result. - -For non-publish builds (PRs, pushes to main), HEAD is not tagged. GitVersion walks history, finds the most recent matching tag (which might be from any package), and computes the next version from there. The version returned in this context is used by `@shellicar/build-version` during the CI build but is not used for publishing, so correctness here is less critical. It will at least return something coherent rather than always falling back to `1.0.0`. - -**Workflow impact**: Both `node.js.yml` and `npm-publish.yml` run GitVersion by installing it via curl and running `gitversion -showvariable SemVer`. Both pick up `GitVersion.yml` from the repo root automatically. Neither workflow has any workflow-level GitVersion configuration, so the `GitVersion.yml` change is sufficient for both. No workflow edits needed. - -**Files changed**: Only `GitVersion.yml`. One line added. - - -# 00:22 - -**Correction to above**: `tag-prefix: '.*@'` causes a crash. GitVersion 6 applies the tag-prefix regex when parsing `next-version: 1.0.0`, not only when matching git tags. Since `1.0.0` has no `@`, the match fails with "Failed to parse 1.0.0 into a Semantic Version". - -The fix is `tag-prefix: '(.*@)?'` - wrapping in an optional group. When parsing `1.0.0`, the prefix matches zero characters and the bare semver parses fine. When processing a tag like `build-clean@1.2.0`, the group matches `build-clean@` and strips it. Both cases tested locally and confirmed working. - - -# 00:29 - -**Further correction**: `(.*@)?` was unnecessary. The crash with `.*@` was caused by `next-version: 1.0.0` giving the `ConfiguredNextVersion` strategy something to parse against the regex. Removing `next-version` is the right fix. Without it, GitVersion has nothing to fail on when there are no release tags. With `tag-prefix: '.*@'` and no `next-version`: - -- No release tags: returns `0.0.21-fix-gitversion-publish-tag.1` (counting from the start of history) -- HEAD tagged `build-clean@1.0.0`: returns `1.0.0` - -`next-version` is a concept for workflows that don't use tags. This workflow does. It was never needed here. +The fix is to remove `next-version` entirely. `next-version` is only meaningful for workflows that don't use tags to track releases. This workflow does. It was never needed. diff --git a/GitVersion.yml b/GitVersion.yml index 7f7ad35..ee4146a 100644 --- a/GitVersion.yml +++ b/GitVersion.yml @@ -1,7 +1,6 @@ increment: Patch tag-prefix: '.*@' strategies: -- ConfiguredNextVersion - MergeMessage - TrackReleaseBranches - VersionInBranchName