Ash - to test it out, simply label your own PR with "use fork ci" and trigger the workflow (push any change). The participants of the pilot get this auto-labeled, but maintianers could apply it manually as well.
https://github.com/apache/airflow/blob/0ae09c32182e2fd0f4f50b1ce423dd1b42f77343/contributing-docs/18_contribution_workflow.rst#ci-in-your-fork --- +1 (binding) from me, this is really needed at this point of time. Shahar On Wed, Nov 4, 2026 at 2:52 PM Ash Berlin-Taylor via dev < [email protected]> wrote: > Before I vote on this, is there a way I can test out the proposed > model/changes so I can see what the flow looks like, both from a maintainer > and a contributor? > > > On 4 Nov 2026, at 11:06, Jarek Potiuk <[email protected]> wrote: > > > > Hello everyone, > > > > I am calling a vote on AIP-120, "Your PR, your CI" [1]. As I said when > > I withdrew the earlier [RESULT] and reopened the discussion [2], this > > goes to a vote rather than [LAZY CONSENSUS], because not everyone who > > objected has withdrawn their objection. > > > > AIP-120 will change to ADIP-12 if the separate [LAZY CONSENSUS] on the > > new ADIP wiki section passes [3]. That only changes where the page > > lives and what it is called. This vote does not depend on it. > > > > What we are voting on > > --------------------- > > > > Whether to switch on CI in contributors' forks for all external > > contributors, as described in AIP-120 [1] and the design [4]: > > > > * PRs from external contributors run CI in the contributor's own fork, > > on GitHub's free runners, instead of on the ASF runners. Committers, > > collaborators and exempted organisations keep project CI, unchanged. > > > > * A contributor enables one workflow in their fork, once. After that a > > plain "git push" runs CI. No PR against their own fork is needed, and > > "breeze ci audit" checks the setup. > > > > * The PR shows the fork run as a commit status linking to the run. A PR > > is drafted when the fork needs setup or the run failed, and undrafted > > when the run is green. A run in progress does not draft it. > > > > * A green fork run is not enough when the PR changes what decides which > > jobs run and on which runners (workflows, breeze sources and similar). > > Such PRs stay visible for review, but wait for a maintainer to run > > project CI with the "use project ci" label. Maintainers can use that > > label on any PR they want verified in project CI before merging. > > > > * A gated PR with no fork CI activity for 7 days is closed, and can be > > reopened. > > > > Not part of this vote: > > > > * The one-time reset of the open PR backlog. It is not proposed here. > > * Which organisations are exempted. That is agreed separately on this > > list. > > > > Where things stand > > ------------------ > > > > The implementation is merged and switched off for everyone except the > > pilot: "enabled = false" in .github/fork-ci-gate.toml. If the vote > > passes, I will post a final pilot update on this list and then switch > > it on in a separate PR. Rollback is setting "enabled = false" again. If > > the vote does not pass, it is not switched on for all external > > contributors. > > > > What the pilot showed > > --------------------- > > > > Seven external contributors joined the opt-in pilot on 2026-10-31. So > > far 16 new PRs carry the "fork ci required" label, 9 of them merged, > > plus some older PRs that were rebased. Feedback is in the > > #internal-airflow-ci-cd Slack channel. Some quotes: > > > > "So far, this has been far less inconvenient that I expected. The > > only downside is that the CI workflow takes a bit longer on my own > > fork that when using the projects runners." - Sameer Mesiah > > > > "Total run time was ~30 minutes, which is basically on par with how > > long it was taking on the shared Apache CI (for this PR > > specifically)." - Justin Pakzad > > > > "I was actually quite surprised that the runtimes were pretty close > > (in some cases quicker) on my fork. I only tested a provider/task-sdk > > PRs, I'm assuming larger core changes will def take longer." - Justin > > Pakzad > > > > "I love it that I can finally rerun failed jobs since they're running > > on the fork" - Iliya Romm > > > > That last one was a benefit we did not plan: contributors can restart > > a single failed job themselves, without asking a maintainer. > > > > It was not all smooth, and that is what the pilot was for: > > > > "this had a green (main) CI run, with two maintainer approvals, then > > I rebased and the fork CI failed, which auto-marked the PR as draft. > > [...] I think the auto-draft rules should be more careful." - Iliya > > Romm > > > > "My PR only changes documentation [...] but fork CI converted it to > > draft automatically." - Aaron Chen > > > > "GitHub just disabled it without any notification, so my workflows on > > fork silently stopped" - Andrew Chang > > > > Improvements made after the pilot started > > ----------------------------------------- > > > > * Rebased pilot PRs are now gated, not only new ones, and a required > > "CI run started" check shows from the moment of the push (#76148). > > * Cancelled project CI runs no longer leave a mixed red/green status > > on the PR (#76148). > > * A run in progress no longer drafts a PR, so rebasing an approved PR > > does not draft it unless the new run fails (#76151). > > * One pending status links to the fork run, replacing a wall of pending > > jobs. This also spends fewer GitHub API writes, and we now watch the > > rate limits (#76154). > > * Scheduled workflows are skipped in forks. They were the likely reason > > GitHub disabled Actions on some forks (#76243). > > * "breeze ci audit" checks that the fork's GitHub Actions can actually > > run (#76136, by Andrew). > > * Only changes that can steer CI are held for a maintainer, and they > > are no longer drafted, so docs under dev/breeze/ pass normally > > (#76282). > > * Fork CI PRs that change CI files no longer get the misleading "need > > workflow approval" label (#76289, by Andrew). > > * A re-run that passes now replaces the failed job statuses on the PR > > (#76327). > > * Fork image names are lowercased in the PROD image example tests > > (#76143), the contributor docs were improved (#76272, by Aaron), and > > transient GitHub errors no longer cause repeated alerts (#76185). > > > > Still open: > > > > * Status on the PR lags, because the monitor runs every 15 minutes. > > Aaron saw the first bot action after about 23 minutes. > > * The monitor's budget for job status writes still fills up with > > several large fork runs active. We need to watch this as more > > contributors join. > > * A failed run after a rebase still drafts the PR, which can cancel > > auto-merge when the failure is a flaky test. Iliya also suggested that > > maintainer approvals could count towards running project CI. > > * The labels are confusing and could use better names. > > * Pilot PRs were mostly small to medium. Large core changes have had > > little testing. > > > > The objections > > -------------- > > > > You should vote knowing what was raised. Please read the original > > thread [5] and the [RESULT] thread [6] rather than rely on my summary. > > > > * Ash's main objection is that this optimises for the wrong thing: the > > problem is PRs not being reviewed, and making contributors run CI > > does nothing about that backlog. Ash also pointed out that allowing > > contributors to run CI in forks and forcing them to are separate > > things. This vote is about requiring it. Ash has not withdrawn this > > objection. > > > > My answer: it does not add review capacity, and I do not claim it > > does. The aim is to slow down iteration on big PRs, so that fewer of > > them compete for review, and to move the cost of getting a PR green > > to its author. How much that helps is my expectation, not a measured > > result. > > > > * Ash and Dennis both raised the effect on new contributors. Dennis > > described it as a big barrier to entry, and Ash the case of someone > > doing all the setup only to have the PR rejected afterwards. > > > > My answer: the setup is now one step, with no second PR and no > > sorting through workflow files, but it is still an extra step that a > > new contributor did not have before. That cost is real. The pilot > > participants are experienced contributors, so the pilot does not tell > > us how a first-time contributor will find it. > > > > * Slower CI for big PRs is intended, but it should be stated plainly. > > On 2026-10-05 I estimated about 85 minutes or more for a full matrix > > run in a fork. The first real full run (#75695) took about 2 hours 40 > > minutes. > > > > On the other side, Arrow, DataFusion and SeaTunnel already run PR CI in > > contributors' forks, or are moving to it, mainly to reduce pressure on > > the shared ASF runners. For us that is a side benefit. > > > > How the vote works > > ------------------ > > > > This is a procedural vote, for the reasons in [2]: where CI runs for > > contributors' PRs is a decision about how the project operates, not a > > change to Airflow itself or its public interfaces. Hussein asked about > > this on the [RESULT] thread, and nobody objected to it in the reopened > > discussion. > > > > It passes with at least 3 binding +1 votes and more binding +1 than -1 > > votes [7]. Everyone is welcome to vote; votes from PMC members are > > binding. A single -1 does not block it, but I will respond to every -1. > > > > The vote runs until 2026-11-09 12:00 UTC. That is longer than the > > 72-hour minimum because of the Summit Reconnect on 4-5 November and the > > weekend. > > > > [ ] +1 Switch on CI in contributors' forks for external contributors, > > after a final pilot update > > [ ] 0 No opinion > > [ ] -1 Do not do this, because... > > > > [1] > https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks > > [2] https://lists.apache.org/thread/h5qsfqthmsqoh5j7wyy12r90mnnvz8kt > > [3] https://lists.apache.org/thread/qxjx3lnwm8gro0dstqr3cvgyj5jg6hyk > > [4] > https://github.com/apache/airflow/blob/main/dev/breeze/doc/ci/08_fork_ci_for_external_contributors.md > > [5] https://lists.apache.org/thread/w74655o8y1jzrzcnygntyyovocf7zmzj > > [6] https://lists.apache.org/thread/krl1bzszlfgfz70m494rm8jq1ph6dr01 > > [7] https://www.apache.org/foundation/voting.html > > > > J. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
