Skip to content

Keep breeze verify working when dry-run is on - #75713

Merged
potiuk merged 1 commit into
apache:mainfrom
shahar1:fix-breeze-verify-dry-run
Oct 27, 2026
Merged

potiuk merged 1 commit into
apache:mainfrom
shahar1:fix-breeze-verify-dry-run

Conversation

@shahar1

@shahar1 shahar1 commented Oct 27, 2026

Copy link
Copy Markdown
Contributor

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.


Was generative AI tooling used to co-author this PR?
  • Yes (please specify the tool below)

  • Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
  • For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
  • When adding dependency, check compliance with the ASF 3rd Party License Policy.
  • For significant user-facing changes create newsfragment: {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.

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.
@potiuk
potiuk merged commit a5ff71d into apache:main Oct 27, 2026
257 of 259 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

Backport successfully created: v3-4-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status Branch Result
✅ v3-4-test PR Link

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants