Repository navigation
Skip the candidate wheel build on PR heads that predate the release tooling - #9476
Merged
Merged
Conversation
…ooling The "Unpublished release wheel" job checks out the reviewed PR head (not the merge commit) and runs .github/release_lock.py and .github/release_build.py from that checkout. A branch opened before those scripts landed on main has nothing to run and fails with "can't open file"; #9422 hit this at 04:15Z today and 27 of the 30 open PRs would on their next push. Detect the two scripts on the head and skip the build steps with a notice when they are absent. The ReleaseLock job still checks the committed lock on the merge commit for every PR. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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
1 participant
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.
Problem
The "Unpublished release wheel (rc1, final)" job added in PolicyEngine/policyengine-us#9467 checks out
github.event.pull_request.head.shaand runs.github/release_lock.pyand.github/release_build.pyfrom that checkout. The workflow definition comes from the merge ref, so the job runs on every open PR, but the two scripts exist only on heads that include #9428 (9/12) and #9467 (today). Any older head fails at the first script:PolicyEngine/policyengine-us#9422 hit this at 04:15Z today (run 34928136338). As of this morning 27 of the 30 open PRs have a head without
release_build.py, so each of them goes red on its next push.Building from the reviewed head rather than the merge commit is deliberate: the retained wheel is meant to be the reviewed source. Running the scripts from a second checkout of the base branch does not help, because both resolve the repository root from their own location and check the head's
pyproject.tomlanduv.lock, and a head that predates the lock regime cannot pass that check anyway.Change
Add a step after the head checkout that detects both scripts. When either is missing, emit a notice ("merge main into the branch to build its candidate wheel") and skip the remaining steps, so the job reports success without an artifact. The
ReleaseLockjob still validates and rehearses the committed lock on the merge commit for every PR, so no PR loses that check. Heads that carry the tooling build exactly as before.Alternative considered: drop the
ref:so the job builds the merge ref like every other job inpr.yaml. That makes the wheel buildable for any mergeable PR but the receipt then names a merge commit nobody reviewed. This PR keeps the head-exact design.Verification
pr.yamlparses; theCandidateWheeljob has 11 steps and every step after the detection carriesif: steps.tooling.outputs.present == 'true'.RELEASE_LOCK_REAL_UV=1 python -m unittest discover -s .github/tests -p 'test_release_*.py'passes (43 tests).🤖 Generated with Claude Code