Yes. What Shahar wrote - that was also from the beginning part of the AIP-120 proposal - having labels, way to test it - and we already tried it over last 2 weeks, made a number of improvements, have a few edge cases to handle (all described in the VOTE email) and thread open in #contributors where we discussed all that. The email in the devlist above is just a summary of it.
So - absolutely, Ash - add "use fork ci" on your PRs and you will get the experience. Even more - you can actually, review, rebase, re-run, review, and approve any of the PRs from the people listed in https://github.com/apache/airflow/blob/main/.github/fork-ci-gate.toml - who offered to test it during the pilot. Report issues or raise concerns if you want, and we (and even some of the contributors who volunteered to pilot it) are addressing any issues and ironing the wrinkles within hours. We have a whole team of people who are able to help address any of your concerns there (and they did so over the last 2 weeks). J. On Wed, Nov 4, 2026 at 12:40 PM Shahar Epstein via dev < [email protected]> wrote: > 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] > > > > >
