Repository navigation
[v3-4-test] Sync recent CI changes from main - #75824
Merged
Merged
Conversation
…#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)
…5675) 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)
…ries (#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)
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)
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)
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)
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)
* 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)
potiuk
requested review from
amoghrajesh,
ashb,
bugraoz93,
gopidesupavan and
jscheffl
as code owners
October 27, 2026 21:21
potiuk
requested review from
choo121600,
ephraimbuddy,
jason810496,
jedcunningham and
vatsrahul1001
as code owners
October 27, 2026 21:21
shahar1
approved these changes
Oct 27, 2026
potiuk
enabled auto-merge (squash)
October 27, 2026 21:23
potiuk
disabled auto-merge
October 27, 2026 21:42
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.
Brings the CI changes merged to
mainsincev3-4-testbranched (2026-10-13) that were not yet backported, so the release branch runs the same CI tooling asmain. One commit per original PR, each cherry-picked with-x; none of them needed conflict resolution.Not included:
v3-4-test(the cherry-pick is empty): Pin the real selective-checks auto-approve test to main #75682, Make Breeze Kubernetes image tests independent of the branch #75724.common.aiprovider changes that are not on this branch: Run the OpenAI Agents adapter tests in the agent framework CI job #74768.v3-4-testalready, through its own CI environment upgrades: [main] Upgrade important CI environment #73822, Update minium uv version to 0.13.4 to address untrustworthy intermediate CA #75296, Bump the github-actions-updates group with 7 updates #75293, Bump the uv-dependency-updates group across 1 directory with 4 updates #74509.main: Update my CODEOWNERS entries to focus on AI providers and the registry #74795 (CODEOWNERS), Re-enable backporting to v3-4-test #74798 (backport configuration), Disable branch protection on v3-4-stable #75473 and Re-enable branch protection on v3-4-stable #75477 (.asf.yamlbranch protection), Fix stale bot skipping older PRs #75761 (stale.yml, a scheduled workflow, which runs from the default branch only).Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Claude Opus 5) following the guidelines
🤖 Generated with Claude Code