Repository navigation
fix(promote): find the draft release by listing and publish it under its tag - #2220
Merged
Merged
Conversation
…its tag The publish job looked the release up with `gh release view v<semver>`. A draft has no tag yet, so the lookup answered 404 for exactly the release the job exists to publish, and the 0.7.0 promotion failed there. Publishing a draft without naming tag_name also tags it with the draft's untagged-<hex> placeholder rather than v<semver>. The job now finds the release by listing releases and matching tag_name, refuses when more than one carries the tag, and publishes by id with tag_name and target_commitish set.
Contributor
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Contributor
|
Approved: no findings at Nothing to do. Clobber: none: |
Contributor
There was a problem hiding this comment.
correctness
minimal-review — approved
Verdict APPROVE — No findings.
security
minimal-review — approved
Verdict APPROVE — No findings.
supply-chain
minimal-review — approved
Verdict APPROVE — No findings.
Panel: 3 of 3 personas ran (correctness, security, supply-chain).
2 tasks done
yermakoffivan
pushed a commit
to yermakoffivan/minimal
that referenced
this pull request
Oct 22, 2026
* fix(promote): find the draft release by listing and publish it under its tag (gominimal#2220) The publish job looked the release up with `gh release view v<semver>`. A draft has no tag yet, so the lookup answered 404 for exactly the release the job exists to publish, and the 0.7.0 promotion failed there. Publishing a draft without naming tag_name also tags it with the draft's untagged-<hex> placeholder rather than v<semver>. The job now finds the release by listing releases and matching tag_name, refuses when more than one carries the tag, and publishes by id with tag_name and target_commitish set. * fix(deps): bump rustls-webpki and webpki-root-certs past the emSign advisories (gominimal#2466) RUSTSEC-2026-0382 (rustls-webpki 0.103.15) and RUSTSEC-2026-0383 (webpki-root-certs 1.0.9), both published 2026-10-20, red cargo-deny on every PR. rustls-webpki 0.103.16 rejects paths through the distrusted emSign intermediates, and webpki-root-certs 1.0.10 drops the emSign ECC Root CA - G3. Lockfile-only change. (cherry picked from commit c0ac8c5) * chore(release): bump version to 0.7.1 Hotfix release carrying the rustls-webpki and webpki-root-certs bumps from gominimal#2466 (RUSTSEC-2026-0382, RUSTSEC-2026-0383) onto 0.7.0. Claude-Session: https://claude.ai/code/session_01FnY4WzhrnmSEByMntmqsVF
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
The stable promotion of 0.7.0 (run 38675564768) pointed the channel at 0.7.0, but its
publishjob failed withno GitHub Release v0.7.0. The release had to be published by hand. This fixes the two causes.gh release view v<semver>. A draft has no tag yet, so both that command andreleases/tags/<tag>return 404, for exactly the release the job exists to publish. The job now lists releases and matchestag_name, which the listing does report for a draft. It refuses if more than one release carries the tag.tag_nameuses the wrong tag. When I published the 0.7.0 draft by id withouttag_name, GitHub tagged ituntagged-<hex>rather thanv0.7.0. That needed a second edit and a tag deletion to repair. The job now publishes by id withtag_nameandtarget_commitishset, plusmake_latesttrue, or false for a prerelease.The already-public path is unchanged: re-runs and rollbacks still check that the tag sits on the release's target.
The same lookup was in
publish-packages.ymlbefore #2214 moved it here. That file is still onmain, somainneeds the same fix. The forward-port PR carries it.Test plan
actionlint .github/workflows/promote.yml: clean.PATCHas anecho, and ran it against the live API withGITHUB_REPOSITORY=gominimal/minimal:VERSION=0.7.0:GitHub Release v0.7.0 is already published at 3539ace0f…; leaving it as it isVERSION=9.9.9:no GitHub Release v9.9.9 — …VERSION=abc123:promoted version 'abc123' is not a semver (a nightly sha) — nothing versioned to publishtag_name == "v0.7.0"returned the draft. Re-publishing release 413354529 withtag_name=v0.7.0moved it torefs/tags/v0.7.0on3539ace0f. The full job runs for the first time on the next stable promotion.