fix(ci): base the fork version on upstream's tags, not the fork's stale copy - #15
Closed
alphyriver wants to merge 1 commit into
Closed
fix(ci): base the fork version on upstream's tags, not the fork's stale copy#15alphyriver wants to merge 1 commit into
alphyriver wants to merge 1 commit into
Conversation
…le copy The fork has been publishing v2.3.0.postN since 21 July while upstream shipped 2.4.0, 2.4.1 and 2.4.2. v2.3.0.post7 is in fact upstream v2.4.1 plus the fork's work - v2.4.1 tags 2f4d237, exactly the commit #13 merged. next-fork-version.sh is not at fault: it picks the nearest reachable PLAIN upstream tag, and its reset-on-new-upstream behaviour is already covered by test_fork_version_sequence_and_upstream_reset. The input was starved. `actions/checkout` brings only the FORK's tags, and fork-upstream-sync.yml fetches upstream with `main:refs/remotes/upstream/main` - no --tags. So upstream release tags never enter the fork, the base froze at the newest one that happened to be here (v2.3.0), and the counter kept climbing. Fetching them in the version job restores the intended behaviour: without the step: v2.3.0.post8 with the step: v2.4.1.post1 The tags land only in that ephemeral runner. The release job pushes the single computed tag (`git push origin "$TAG"`) and nothing anywhere runs `push --tags`, so the fork's published tag namespace and its `tags: ["v*"]` build trigger are unaffected. Mirroring upstream tags into the fork instead was considered and rejected: pushing v2.4.x would fire Fork Image once per upstream release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
AI review is unavailable: DeepSeek API error: DEEPSEEK_API_KEY is not set Please review this PR manually. |
Owner
Author
|
Superseded by #14. The version fix has to land together with the code change: merging either alone triggers Fork Image, and without the fix that run would mint another mislabelled |
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
1 participant
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.
The bug
The fork has published
v2.3.0.postNsince 21 July while upstream shipped 2.4.0, 2.4.1 and 2.4.2.v2.3.0.post7is actually upstream v2.4.1 plus the fork's work — v2.4.1 tags2f4d237, exactly the commit #13 merged.Root cause — not the script
next-fork-version.shpicks the nearest reachable plain upstream tag, and its reset-on-new-upstream behaviour is already covered bytest_fork_version_sequence_and_upstream_reset. The script was fine; its input was starved:actions/checkoutbrings only the fork's tags.fork-upstream-sync.ymlfetches upstream asmain:refs/remotes/upstream/main— no--tags.So upstream's release tags never enter the fork. The base froze at the newest one that happened to be here (v2.3.0) and the counter just kept climbing.
Confirmed by inspection: the fork's tag list ends at
v2.3.0; upstream hasv2.4.0,v2.4.1,v2.4.2. Of those, v2.4.0 and v2.4.1 are ancestors of our merged HEAD; v2.4.2 landed upstream after our sync point.The fix
Fetch upstream's tags in the
versionjob, immediately before computing. Verified locally by running the exact CI sequence:The tags land only in that ephemeral runner. The release job pushes the single computed tag (
git push origin "$TAG"), and nothing anywhere runspush --tags— so the fork's published tag namespace and itstags: ["v*"]build trigger are untouched.Alternative considered and rejected: mirroring upstream tags into the fork during sync. It would make
git describemeaningful repo-wide, but pushingv2.4.xfires Fork Image once per upstream release. Not worth it for a value only the version job needs.No new test
The script's reset logic is already pinned. The remaining gap is CI wiring, and this repo has no precedent for workflow-asserting tests — adding that pattern for one step felt like the wrong trade. The step fails loudly if the fetch ever breaks (default
set -e), which is the failure mode that matters.Merge order
Worth merging before #14: any qualifying push to
maintriggers Fork Image, and without this it would mint another wrongv2.3.0.post8.🤖 Generated with Claude Code