fix: peel annotated tags in the broker's tag rule - #188
Merged
Merged
Conversation
- The compare API rejects a tag object, and an annotated tag's sha claim can name one; the commit under it is what ran, and tag objects are immutable, so peeling keeps the claim authoritative.
Contributor
soothfast gate |
Verdenroz
added a commit
that referenced
this pull request
Sep 6, 2026
## What changed Cuts v0.3.1. The `Unreleased` heading becomes `## 0.3.1 - 2026-09-06` with Overview and Upgrade notes written, the workspace version and the eight intra-workspace requirements move from 0.3.0 to 0.3.1, the lockfile follows, and the README dependency snippet and `soothfast.toml` site version match. Two wording fixes ride along: the 0.3.0 Overview no longer compares soothfast to another product, and a `docs/spec.md` example uses a placeholder crate name instead of a real project's. ## Why The one-step action in 0.3.0 could not run a bench target that declares `required-features`, could not diff the changelog over a crate without a bench, and had no way to land derived files outside its built-in regeneration. #187 adds inputs for each and #188 hardens the broker's tag rule against annotated tag objects. Both are action and broker changes, but the release workflow requires the tag to match the workspace version, so they ship as a patch release of the crates too. The frozen section was read against master d5d84f4 after the last changelog regeneration and lists exactly the two merges since v0.3.0. ## How was this tested - `make check` on this tree (fmt, clippy `-D warnings`, `cargo test --workspace --all-features`): exit 0, 25 test binaries green. - `cargo metadata --offline` refreshed `Cargo.lock`; the diff is ten version lines and nothing else. - The tag push runs `release.yml` end to end, including the tag-object peel now live in the broker. ## Checklist - [x] `make check` passes (fmt, clippy `-D warnings`, `cargo test --workspace`) - [ ] `make gate BASE=master` passes, or any intentional cost change is explained above - [ ] Tests added/updated for new behavior (not required for docs/CI-only changes) - [ ] Public API items have `///` doc comments - [x] No new dependency, or its justification is included above (see [Dependency Policy](../CONTRIBUTING.md#dependency-policy)) - [x] Docs (`README.md`, `docs/`, `soothfast:bind`/`soothfast:claim` markers) updated if behavior changed
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.
What changed
The broker's tag rule compared the default branch against the OIDC
shaclaim as given. For an annotated tag that claim can name the tag object rather than the commit under it, and the compare API rejects a tag object with a 404, which the broker would surface as a 502 and no release. The broker now asks for/git/tags/{sha}first and compares the commit it points at; a 404 there means the claim already named a commit and it is used as is.tagObjectto the GitHub client (GET /repos/{repo}/git/tags/{sha}, undefined on 404).decideRefpeels before comparing, with a two-line comment stating why the claim stays authoritative: tag objects are immutable.Why
The tag rule exists so a release runs only code already on the default branch. The v0.3.0 run carried the commit SHA and passed, but the compare API's behaviour on a tag object was measured rather than assumed, and it fails. Peeling closes that without weakening the rule.
How was this tested
npm testinbot/: 67 passed, 0 failed, including the two new tests.tsc --noEmit: clean.bot.ymland exercises it live.make checkandmake gatenot run; no Rust changed.Checklist
make checkpasses (fmt, clippy-D warnings,cargo test --workspace)make gate BASE=masterpasses, or any intentional cost change is explained above///doc commentsREADME.md,docs/,soothfast:bind/soothfast:claimmarkers) updated if behavior changed