Repository navigation
ci(release): push only the release tag - #465
Conversation
Tiny Sweeper reviewTiny Sweeper reviewed this change across 5 lane(s) and found 0 active actionable finding(s). Detailed lane evidence and any incomplete work are listed below. _The code index is behind this pull request (indexed at `42fdeeb02be5`), so retrieved context may be out of date._ State: Incomplete Review snapshot
Completeness: Incomplete What changedThe release workflow previously tried to push both the release commit to main and the release tag; the commit push was always rejected because the "Protect main" ruleset requires a pull request for every change to main (GH013). The step is now narrowed to pushing only the tag (`refs/tags/${RELEASE_TAG}`), with a comment explaining the ruleset conflict. The release commit itself stays off main, and the next version computation is unaffected because `next-release-version.sh` derives the base version from tags, which are refreshed via `git fetch --tags`. The tag push carries the release commit's objects, so nothing else in the workflow depends on main being updated. Permissions, actions, and interpolations are unchanged; `RELEASE_TAG` continues to come from the validated semver script output rather than untrusted input. The manifest-bump side effect on main (the workspace version left stale) is disclosed in the description and is exactly the case the version script was written to handle. Features
TestsNo supported feature-to-test mapping was produced. Test execution is not inferred. FindingsNo active actionable findings. Could not review: .github/workflows/release.yml Before merge
Agent review detailscritique
security
tests
commits
description
Evidence and run details
|
There was a problem hiding this comment.
tinysweeper found nothing blocking, but could not review everything, so this is not an approval: .github/workflows/release.yml.
$0.0026 · 37,430 in / 8,413 out · 0 cached (0%) · ladder/vectors-oai3, glm-5.3-flash · 109 embedded
critique: $0.0020 · 14,124 in / 6,290 out · 0 cached (0%) · glm-5.3-flash
security: $0.0001 · 13,874 in / 47 out · 0 cached (0%) · glm-5.3-flash
description: $0.0001 · 6,536 in / 604 out · 0 cached (0%) · glm-5.3-flash
The Protect main ruleset requires a pull request for every change to main, so pushing the release commit to main is always rejected (GH013). Push only the tag; the next version already comes from the tags.
b94274e to
224295d
Compare
There was a problem hiding this comment.
tinysweeper found nothing blocking, but could not review everything, so this is not an approval: .github/workflows/release.yml.
$0.0021 · 43,301 in / 3,088 out · 5,184 cached (12%) · ladder/vectors-oai3, glm-5.3-flash · 57 embedded
security: $0.0012 · 28,914 in / 1,462 out · 0 cached (0%) · glm-5.3-flash
description: $0.0007 · 12,778 in / 1,041 out · 5,184 cached (41%) · glm-5.3-flash
Summary
The Release workflow still pushes its release commit to
main, and the "Protect main" ruleset rejects that push every time. This PR only removes that push. The version logic is already on main (.github/scripts/next-release-version.sh, from 3413d2d onward) and is not touched.GH013: Repository rule violations found for refs/heads/main ... Changes must be made through a pull request/! [remote rejected] HEAD -> main. Runs 38714692861, 38347365938 and 37189411952 failed the same way.~DEFAULT_BRANCH, with the rules deletion, non_fast_forward, pull_request and required_status_checks, and 0 bypass actors. It is the repo's only ruleset; nothing targets tags.refs/tags/vX.Y.Z. The release commit (the bumpedCargo.toml/Cargo.lock) stays on the runner, reachable from its tag. A comment explains why main is never pushed.API Or Behavior Changes
main; the tag is the released version's only ref.[workspace.package].versionon main keeps lagging the tags, which the existing script already handles (it bumps from the higher of the manifest and the highest tag).tinyagents-harness(and every crate incrates/*) haspublish = false, so the package and publish steps stay skipped.Tests
Workflow-only change.
actionlintis not installed locally, so it was not run. The file parses as YAML (RubyYAML.load_file). Release isworkflow_dispatch-only, so this PR's CI doesn't exercise it; the first dispatch after merge is the real check.cargo fmt --check(N/A: workflow-only change)cargo clippy --all-targets -- -D warnings(N/A)cargo clippy --all-targets --all-features -- -D warnings(N/A)cargo build --all-targets(N/A)cargo build --all-targets --all-features(N/A)cargo test(N/A)cargo test --all-features(N/A)Documentation
A comment in
release.ymlon the push step. Not changed: ruleset settings (an admin action). Adding a bypass actor for the release job instead would keep main's manifest version in step; that's the maintainer's call.Summary by CodeRabbit