Repository navigation
Refuse to publish constraints when the branch moved during generation - #75989
Merged
Merged
Conversation
A regular constraints refresh resolves its pins against the constraints branch as it is when the run starts, then commits them on top of the branch as it is when the run ends. When Release constraints commits a release candidate's pins in between, the refresh overwrote them with pins resolved against the older baseline, and the push still succeeded because it was an ordinary fast-forward. The two workflows run in different concurrency groups, so nothing serialised them. The publish now fails instead and asks for a re-run, which then starts from the candidate's constraints. Generated-by: Claude Opus 5
boring-cyborg
Bot
added
area:dev-tools
backport-to-v3-4-test
potiuk
requested review from
amoghrajesh,
bugraoz93,
choo121600,
ephraimbuddy,
jason810496,
jedcunningham,
jscheffl and
vatsrahul1001
as code owners
October 29, 2026 18:13
vatsrahul1001
approved these changes
Oct 29, 2026
shahar1
enabled auto-merge (squash)
October 29, 2026 18:24
Contributor
RunsOn re-runs them automatically when the run finishes; no action is needed. |
potiuk
disabled auto-merge
October 29, 2026 18:44
potiuk
enabled auto-merge (squash)
October 29, 2026 18:44
potiuk
disabled auto-merge
October 29, 2026 18:44
Contributor
Backport successfully created: v3-4-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
vatsrahul1001
pushed a commit
that referenced
this pull request
Oct 29, 2026
…g generation (#75989) A regular constraints refresh resolves its pins against the constraints branch as it is when the run starts, then commits them on top of the branch as it is when the run ends. When Release constraints commits a release candidate's pins in between, the refresh overwrote them with pins resolved against the older baseline, and the push still succeeded because it was an ordinary fast-forward. The two workflows run in different concurrency groups, so nothing serialised them. The publish now fails instead and asks for a re-run, which then starts from the candidate's constraints. (cherry picked from commit 92bbf67) Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Generated-by: Claude Opus 5
github-actions Bot
pushed a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Oct 29, 2026
…g generation (apache#75989) A regular constraints refresh resolves its pins against the constraints branch as it is when the run starts, then commits them on top of the branch as it is when the run ends. When Release constraints commits a release candidate's pins in between, the refresh overwrote them with pins resolved against the older baseline, and the push still succeeded because it was an ordinary fast-forward. The two workflows run in different concurrency groups, so nothing serialised them. The publish now fails instead and asks for a re-run, which then starts from the candidate's constraints. (cherry picked from commit 92bbf67) Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Generated-by: Claude Opus 5
vatsrahul1001
pushed a commit
that referenced
this pull request
Oct 30, 2026
…g generation (#75989) (#75990) A regular constraints refresh resolves its pins against the constraints branch as it is when the run starts, then commits them on top of the branch as it is when the run ends. When Release constraints commits a release candidate's pins in between, the refresh overwrote them with pins resolved against the older baseline, and the push still succeeded because it was an ordinary fast-forward. The two workflows run in different concurrency groups, so nothing serialised them. The publish now fails instead and asks for a re-run, which then starts from the candidate's constraints. (cherry picked from commit 92bbf67) Generated-by: Claude Opus 5 Co-authored-by: Jarek Potiuk <jarek@potiuk.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
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.
A regular constraints refresh (
update-constraints-on-push.yml, andrefresh-constraints.yml, which calls it) resolves its pins against theconstraints-X-Ybranch as it is when the run starts, then the publish job checks out the branch as it is when the run ends, commits the generated files on top and pushes. IfRelease constraintscommits a release candidate's pins in between, the refresh overwrites them with pins resolved against the older baseline, and the push still succeeds because it is an ordinary fast-forward. The two workflows run in different concurrency groups, so nothing serialises them.This came up in review of #75919, which made the regular generation keep the candidate pins it finds in the baseline. That only helps when the baseline it read is the one it publishes onto.
build-inforecords the commit SHA of the target constraints branch before anything is generated.Recording the baseline before generation is conservative: any commit landing at any point during the run blocks the publish, never only part of the window. A push racing in after the check is still rejected by
git pushas a non-fast-forward. A branch that does not exist yet records an empty SHA, and the check is skipped.The manual-refresh section of
dev/MANUALLY_GENERATING_IMAGE_CACHE_AND_CONSTRAINTS.mdsays what the new failure means and what to do about it.Checks run locally: prek pre-commit stage on the two changed files (yamllint, zizmor, markdownlint and the rest) passed, except
lychee, which needs Docker and was not run. No tests read this workflow.Was generative AI tooling used to co-author this PR?
Generated-by: Claude Opus 5 following the guidelines
🤖 Generated with Claude Code