> * A gated PR with no fork CI activity for 7 days is closed, and can be > reopened.
7 days is too short for many contributors who only do this in spare moments. Please make this 30 days at least. > 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]
