Skip to content

ci: gate release pull requests on the trusted release checks - #1134

Merged
kvlonge merged 4 commits into
mainfrom
ci/release-pr-verify-gate
Oct 18, 2026
Merged

kvlonge merged 4 commits into
mainfrom
ci/release-pr-verify-gate

Conversation

@kvlonge

@kvlonge kvlonge commented Oct 18, 2026

Copy link
Copy Markdown
Contributor

Why

Release pull request #1133 became mergeable seconds after Release Please opened it: the normal Verify job skipped its suites on the version-only commit and produced a successful Verify check run before the trusted release checks pushed the lockfile refresh and posted Verify. It merged with Cargo.lock still at 0.157.0.

Changes

  • Refresh Cargo.lock: the 17 workspace crate versions move to 0.157.1.
  • The native layering check fails when Cargo.lock or uv.lock versions differ from the manifests; release checks run it before dispatching.
  • On Release Please branches the Verify workflow job reports under another name, so only the trusted release checks can post Verify on the current head.
  • New check-release-gate verifies the workflow wiring and is part of check-ci.

Verification

  • Focused release gate and layering tests (45) pass; two fail against the old workflow, covering the chore(main): release 0.157.1 #1133 sequence.
  • check-release-gate and the version check pass; the version check fails on the previous main tree.
  • Independent review: no blockers; the branch-prefix consistency note is fixed.
  • make check-ci passes. End-to-end behaviour is confirmed by the next release.

The release pull request merged before its lockfile refresh landed, leaving workspace crate versions at 0.157.0 in Cargo.lock. This is the same cargo update --workspace result the release workflow produced.
Compare each workspace crate's Cargo.lock entry with its manifest version and
the uv.lock project entry with pyproject.toml, offline, so a release whose
lockfile refresh did not land fails a check instead of merging.
… Verify

Release Please pull requests are version-only, so the Verify workflow skipped
their suites and its Verify check run succeeded within seconds. That check run
satisfied the required Verify before the release job pushed the lockfile
refresh and before its trusted checks posted Verify on the refreshed head.

On same-repository release-please-- branches the Verify workflow's aggregate
job now reports as "Release pull request suites" (it still always runs; a
skipped job would count as passing). The only Verify on such a head is the
commit status from the release checks, so the pull request waits until they
pass on its current head, and every later push waits again. The release
checks also run the offline version check before dispatching anything.

A check-release-gate static check, part of check-ci, models how the ruleset
resolves Verify for release, feature, fork and merge group pull requests
against the real workflow files.
@kvlonge
kvlonge enabled auto-merge (squash) October 18, 2026 01:09
@kvlonge
kvlonge merged commit 437531d into main Oct 18, 2026
43 checks passed
@kvlonge
kvlonge deleted the ci/release-pr-verify-gate branch October 18, 2026 01:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant