Skip to content

ci(release-proposal): do not propose from a superseded commit - #1560

Open
RonnyPfannschmidt wants to merge 1 commit into
pypa:mainfrom
RonnyPfannschmidt:ci/release-proposal-race
Open

RonnyPfannschmidt wants to merge 1 commit into
pypa:mainfrom
RonnyPfannschmidt:ci/release-proposal-race

Conversation

@RonnyPfannschmidt

Copy link
Copy Markdown
Contributor

Written by Claude Opus 5.5 via Claude Code for the setuptools-scm maintainers; I prompted it, it did the work, I read it.

#1558 was a duplicate release PR for vcs-versioning 2.6.0, opened after #1557 had already released it. Merging #1553 and #1557 48 seconds apart raced:

UTC
22:09:44 #1553's merge commit 0762f0c starts a proposal run; the 1556.feature.md fragment is still there, so it plans 2.6.0
22:10:29 #1557 is merged
22:10:32 the 0762f0c run force-pushes release/main, finds no open release PR and opens #1558
22:10:32 the run for #1557's merge commit finds no fragments and does nothing about #1558

Merging #1558 would have re-run the 2.6.0 tagging, which since #1553 refuses a tag at another commit and opens a "did not start" issue.

  • create-release-pr checks that the source branch still points at the run's commit right before pushing; if not, it stops with a notice and the run for the newer commit proposes the release.
  • New close-stale-release-pr job: a push that finds no fragments in either package closes any open release/<branch> PR with a comment, unless the branch has moved on, so an older run cannot close a PR a newer commit's run just opened.

A concurrency group alone would not have prevented this: the race fit inside the 12-second create-release-pr job.

The agent ran the close script against a mocked Octokit (stale PR closed, no PR, superseded run leaves it alone) and the push guard against a local git remote (current commit pushes, superseded commit does not); neither has run on GitHub yet.

Merging pypa#1553 and then pypa#1557 48 seconds apart raced: the proposal run for
pypa#1553's merge commit still saw the 2.6.0 fragment, force-pushed
release/main three seconds after pypa#1557 was merged, found no open release
PR and opened pypa#1558, a duplicate of the release that had just shipped.
Merging it would have re-run the 2.6.0 tagging.

The push step now stops when the source branch no longer points at the
run's commit; the run for the newer commit proposes the release. A push
that finds no fragments in either package closes any release PR still
open for its branch, unless the branch has moved on, so a duplicate that
slips through anyway does not linger.

Co-Authored-By: Claude Opus 5.5 via Claude Code <noreply@anthropic.com>
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