potiuk opened a new pull request, #73319: URL: https://github.com/apache/airflow/pull/73319
Each maintenance branch upgrades its own CI environment on its own schedule, so backporting `main`'s upgrade would race that with a change conflicting on the very files it regenerates. It already does not work. #73233, #73114, #72314 and #72091 all carried `backport-to-v3-3-test` and **none** of them produced a backport, while `backport-<sha>-v3-3-test` PRs exist for other changes — so the machinery is fine, these were failing silently, almost certainly on `uv.lock`. `.github/boring-cyborg.yml` labels by path and cannot tell a generated upgrade PR from a hand-written change touching `dev/` or `.github/`, so the label has to come off afterwards. Two layers, because one is not enough: * `breeze ci upgrade` drops the labels right after creating the PR. * `upgrade-check.yml` sweeps again once the PR has settled. This is the one that usually does the work: boring-cyborg labels on a webhook and `breeze` exits a second or two after creating the PR, so the first pass often runs before the label exists. `automatic-backport.yml` waits for the same reason. Both degrade quietly rather than failing a run whose branch is already pushed: an unreadable label list means nothing is edited (never guess and edit blindly), and a failed edit warns. Only `backport-to-*` labels are touched; everything boring-cyborg adds for area and provider is left alone. --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 5) Generated-by: Claude Code (Opus 5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
