fix(release): refuse a tag that names a version the package does not carry - #633
Merged
Merged
Conversation
…carry Five consecutive tags failed, each one filing a "Release Pipeline Failed" issue, and all five had the same cause: v1.3.3 -> cli 1.3.1 (#599) v1.3.4 -> cli 1.3.1 (#603) v1.3.5 -> cli 1.3.1 (#606) v1.3.6 -> cli 1.3.2 v1.3.7 -> cli 1.3.2 (#627) The pipeline reads the version from two places and never compared them. `publish-npm` reads `package.json` -- correctly -- and since #569 it asks the registry first, so an already-published version is skipped as a non-failure. `smoke-test-functional` then installs `@beyondnet/evolith-cli@${tag#v}`. When the two disagree, publish "succeeds" by skipping and the smoke test dies on `npm error code ETARGET / No matching version found`. Nothing was ever wrong with the build: the tag named a version that was never built. No re-run could fix it, and the run spent a full build, three binary packagings and three platform smoke tests before finding out. The question now lives in `release-gate`, before anything is built or published: if the tag and `src/sdk/cli/package.json` disagree, the run stops with both numbers named and a step summary saying which of the two to change. `release-gate` gains the checkout it needs to read the file. Verified: the assertion logic run against this tree rejects `v1.3.7` (package carries 1.3.2) and accepts `v1.3.2`. Workflow parses as YAML. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: aarroyo <beyondnet.peru@gmail.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
beyondnetPeru
added a commit
that referenced
this pull request
Aug 21, 2026
…carry (#633) Five consecutive tags failed, each one filing a "Release Pipeline Failed" issue, and all five had the same cause: v1.3.3 -> cli 1.3.1 (#599) v1.3.4 -> cli 1.3.1 (#603) v1.3.5 -> cli 1.3.1 (#606) v1.3.6 -> cli 1.3.2 v1.3.7 -> cli 1.3.2 (#627) The pipeline reads the version from two places and never compared them. `publish-npm` reads `package.json` -- correctly -- and since #569 it asks the registry first, so an already-published version is skipped as a non-failure. `smoke-test-functional` then installs `@beyondnet/evolith-cli@${tag#v}`. When the two disagree, publish "succeeds" by skipping and the smoke test dies on `npm error code ETARGET / No matching version found`. Nothing was ever wrong with the build: the tag named a version that was never built. No re-run could fix it, and the run spent a full build, three binary packagings and three platform smoke tests before finding out. The question now lives in `release-gate`, before anything is built or published: if the tag and `src/sdk/cli/package.json` disagree, the run stops with both numbers named and a step summary saying which of the two to change. `release-gate` gains the checkout it needs to read the file. Verified: the assertion logic run against this tree rejects `v1.3.7` (package carries 1.3.2) and accepts `v1.3.2`. Workflow parses as YAML. Signed-off-by: aarroyo <beyondnet.peru@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 21, 2026
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.
Closes the "Release Pipeline Failed" class. Seven issues are open; five of them are one bug.
The bug
The pipeline reads the release version from two places and never compared them.
publish-npmreadssrc/sdk/cli/package.json. Correct — and since publish-npm attempts a publish without asking whether the version already exists #569 it asks the registry first, so an already-published version is skipped as a deliberate non-failure.smoke-test-functionalthen runsnpm install -g @beyondnet/evolith-cli@${tag#v}.When the tag and the package disagree, publish "succeeds" by skipping and the smoke test dies on
npm error code ETARGET / No matching version found.Every recent tag disagreed:
src/sdk/cli/package.jsonv1.3.3v1.3.4v1.3.5v1.3.6v1.3.7That is why npm carries the CLI only up to 1.3.2 while five tags above it exist. Nothing was ever wrong with the build — the tag named a version that was never built, so no re-run could have fixed it, and each run spent a full build, three binary packagings and three platform smoke tests before finding out.
The fix
The question moves into
release-gate, before anything is built or published. If the tag and the package disagree the run stops immediately, naming both numbers and writing a step summary that says which of the two to change: bump the package, or delete the tag and push the one that matches.release-gategains the checkout it needs to read the file — it had none, since until now it only parsedGITHUB_REF.Verification
The assertion logic, run against this tree (package at 1.3.2):
Workflow parses as YAML.
Not in scope
#492, #552 and #553 are the older three, and #569 already fixed their cause — a re-run over an already-published version. They are stale and will be closed with that explanation rather than carried.
🤖 Generated with Claude Code