Repository navigation
Keep breeze verify working when dry-run is on - #75713
Merged
Merged
Conversation
With dry-run on, run_command skips every command and returns empty output. breeze verify only reads git state to list the checks a change needs, so skipping those queries made it crash with an IndexError instead of answering.
shahar1
requested review from
amoghrajesh,
ashb,
bugraoz93,
choo121600,
ephraimbuddy,
gopidesupavan,
jason810496,
jedcunningham,
jscheffl,
potiuk and
vatsrahul1001
as code owners
October 27, 2026 04:51
potiuk
approved these changes
Oct 27, 2026
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.
|
1 task done
potiuk
added a commit
that referenced
this pull request
Oct 27, 2026
* Bootstrap constraints generation for a Python without a baseline file (#74596) The generator always downloads the previous constraints file of the same Python from the constraints branch to diff against it, and failed with a 404 for the first generation of a new Python. When the branch carries the same constraints mode for other Pythons, a missing file means a first publication and the generator diffs against an empty baseline instead. A 404 on a branch without any file of that mode, and every other HTTP error, still fails. (cherry picked from commit d267fbd) * Check out constraints from apache/airflow when diffing them in CI (#75675) The Update constraints job checked out the constraints branch from the repository the run belongs to. Forks do not carry the constraints-* branches, so the job failed on every canary push in a fork. Diff against apache/airflow instead; the job only diffs now, so it needs neither credentials nor history. Generated-by: Claude Opus 5 (cherry picked from commit 3348602) * Always approve workflow runs of PRs from trusted stakeholder repositories (#75677) Amazon, Google and Astronomer maintain large parts of Airflow and open many PRs from their own repositories. Their PRs often touch large providers or CI and wait for a maintainer to approve every push, although only people those stakeholders gave write access can push the commits of these PRs. Generated-by: Claude Opus 5 (cherry picked from commit ffd9398) * Retry GitHub calls that fail to connect in the fork CI monitor (#75701) A monitor run failed to report job statuses for a PR because a POST to the statuses API ended in a TLS handshake timeout. Network failures are as transient as the server errors already retried, and one that happens before the request reaches GitHub cannot have taken effect, so it is safe to repeat even for calls such as creating a comment. Generated-by: Claude Opus 5 (cherry picked from commit 2ae00f1) * Stop breeze k8s commands from silently rewriting uv.lock (#75763) A v3-4-test backport bumped a workspace member's version without updating uv.lock, and the `update-uv-lock` static check still passed. The chart's prek hooks run `breeze k8s setup-env`, which ran a plain `uv sync` in kubernetes-tests. That project is a uv workspace member, so the sync re-resolved and rewrote the root uv.lock before the root hook checked it. Nested prek configs do not inherit the root UV_FROZEN=1, and prek does not report files a nested-project hook modifies outside its own project, so the rewrite went unnoticed and the stale lock was merged. It then broke every "Generate constraints" job on the branch. The `uv run pytest` calls of `breeze k8s tests` and the overlay tests had the same effect on contributors' checkouts. CI now also fails when the static checks leave tracked files modified, so any other hook writing outside its project is caught. (cherry picked from commit 7c7157b) * Keep breeze verify working when dry-run is on (#75713) With dry-run on, run_command skips every command and returns empty output. breeze verify only reads git state to list the checks a change needs, so skipping those queries made it crash with an IndexError instead of answering. (cherry picked from commit a5ff71d) * Tell contributors when their fork CI workflow stops running (#75814) The fork CI monitor read the fork's workflow state only until it first saw the workflow enabled. When the workflow was disabled afterwards, by the contributor or by GitHub after 60 days of fork inactivity, the pull request kept waiting for a push that could never run CI, while its comment still said the workflow was enabled. Contributors now get a new comment telling them why it stopped and how to turn it back on, starting with syncing their fork's main from apache/airflow. breeze ci audit also stops suggesting committers disable the workflow: a committer trying fork CI needs it, and following the hint is one way a pull request ends up stuck like this. Generated-by: Claude Opus 5 (cherry picked from commit 891e83d) * Harden the fork CI reconciler and protect the fork CI gate (#74909) * Retry the fork CI push-again nudge when posting it fails The state comment is what the next reconciler run compares with. Recording awaiting_push there before the nudge was posted meant a failed post was never retried, and the contributor got no prompt before the inactivity closure. Generated-by: Claude Opus 5 * Ignore fork-only workflows that skipped every job in the fork CI tampering check A workflow or trigger the base branch does not have always counted as project CI, so a pull request adding a fork-only workflow that its jobs guard off in apache/airflow was closed for gate tampering although nothing ran. Generated-by: Claude Opus 5 * Keep fork CI pull requests sharing a head commit across bases for a maintainer The green-trust decision is stored as a commit status, which every pull request with that head commit shares. Pull requests with different bases have different changed files, so a decision made for one could mark the other ready without checking it. Generated-by: Claude Opus 5 * Attribute fork CI runs to the right pull request in the tampering check Runs from forks carry no pull request, so they were matched by fork branch alone. Legitimate project CI against a base branch without the gate, made before a retarget, or a run of another pull request from the same branch, could close a gated pull request for gate tampering. Generated-by: Claude Opus 5 * Close fork CI pull requests that change the fork CI gate A pull request whose CI runs in the contributor's fork could change the gate that sent it there: its code, its configuration, the gate job or the monitor. Such a change decides where the pull request's own CI runs, so the monitor now closes it and explains why. Contributors can still add, change or remove their own pilot entry, which is how they join and leave the pilot. Generated-by: Claude Opus 5 * Count only started jobs of fork-only workflows as project CI work A fork-only workflow run cancelled before a runner took its jobs reports them completed and cancelled, so it counted as project CI work. It now uses the same started-job test as ci-amd.yml runs. Generated-by: Claude Opus 5 * Name the cancelled-run CI passed job in the fork CI tampering docs The tampering check now accepts the name a cancelled ci-amd.yml run gives its CI passed job, so the docs list it with the other names of that job. Generated-by: Claude Opus 5 (cherry picked from commit 8058c88) --------- Co-authored-by: Dev-iL <6509619+Dev-iL@users.noreply.github.com> Co-authored-by: Shahar Epstein <60007259+shahar1@users.noreply.github.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.
With dry-run on,
run_commandskips every command and returns empty output.breeze verifyonly reads git state to list the checks a change needs, so skipping those queries made it crash with anIndexErrorinstead of answering.Was generative AI tooling used to co-author this PR?
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.