Could we implement this on a trial basis first? I propose a one-week pilot phase where other active contributors and I can opt-in. We can start by setting up the CI on our personal forks to monitor the results and see how it fits into our workflow.
This trial will allow us to gather real-world data, refine the setup, and ensure a much more precise and stable implementation before we consider making it mandatory for everyone. Thanks & Regards, Pratiksha Badheka On Sat, Oct 10, 2026 at 7:27 AM Andrew Chang <[email protected]> wrote: > Thanks Jarek. I think this is a good idea in general, but I have one > concern: should we still enforce ASF runner CI on every PR? (Of course, > only when they are ready to merge) > > My concern is that I'm not sure contributors' fork CI fully aligns with > main CI. Here's an example I thought of: some checks are only triggered by > the "pull_request" event, but on fork CI, since no pull request is needed, > these checks could be bypassed. > > If we fully trust the result from fork CI and don't enforce CI on the > Apache/Airflow repo, this could be a gap. > > I know the canary run could catch these errors, but the cost still lands on > maintainers: they will need to fix what contributors break, and I think > it's better to keep this cost as the contributors' own responsibility. > > This is just one gap I could think of, and I believe there will be more > gaps like this when we rely on fork CI. > > So I would like to ask if we could still enforce ASF runner CI for every PR > before merge… At least in the very beginning when we introduce this "your > PR, your CI" policy, to avoid these costs coming back to maintainers. > > Thanks, > Andrew > > > Jarek Potiuk <[email protected]>於 2026年10月10日週六，07:58寫道： > > > > The cause is that ci-amd.yml calls many reusable workflows, and each > > matrix sets max-parallel: 20 on its own. Each matrix stays under the > limit, > > but they run side by side and add up. GitHub has no setting that caps the > > whole workflow that I'm aware of. > > > > Yes. GH controls here are heavily limited. But that's even more important > > to do "Your PR -> Your CI" - because then the 20 comes not from the limit > > single workflow has, but this is maximum runners single **contributor** > can > > run - which is even better because it also applies to all PRs that > > contibutor opens. > > r > > If a single contributor today rebases 5 PRs about the same time and all > > those PRs are "significant" - i.e. they trigger the whole matrix of > tests, > > it will take 15 hours or so to get them all completed if we change > approach > > to "Your PR -> Your CI" - and they will use 20 runners max. If they do it > > today where all runners come from ASF, they can use all the free > > runners—i.e., it will take 2 hours—but then it might cause hundreds of > jobs > > running in parallel, and we cannot limit that. > > > > That is the tragedy of the commons we experience now in ASF - where > > distributing shared resources fairly among many users is very difficult, > > and the rules you can set with GH are currently very poor. The rules that > > Infra made are simply "poor" approach to control it with whatever is > > currently available. > > > > On the other hand - distributing the CI to be "per user who submits PR" > is > > **way** more fair - because the user can at most block themselves, not > > others. And they must start prioritizing. We are effectively "shifting > > left" resource management and get rid of the "commons" part. With this > > change, the contributor must start being careful about what they do - > > because they might block themselves, rather than others. > > > > This is really classic "tragedy of the commons" > > https://en.wikipedia.org/wiki/Tragedy_of_the_commons - nothing new, - > it's > > a very well researched economic principle - known and described since > > Aristotle time - and absolutely expected for the kind of shared resources > > (GitHub Runners time) we share: > > > > "The tragedy of the commons is the idea that when a resource is shared > and > > can benefit the individual at a cost to the community, it is rational for > > the individual to overuse the resource, even though this collectively > leads > > to the depletion of the resource for everyone." > > > > T > > > > J. > > > > > > > > On Fri, Oct 9, 2026 at 4:28 PM Justin Mclean <[email protected]> wrote: > > > > > Hi Jarek, > > > > > > One data point for this thread. Infra’s GitHub Actions policy asks for > a > > > cap on workflows at 20 concurrent jobs: > > > https://infra.apache.org/github-actions-policy.html > > > > > > The Tests (AMD) workflow goes over it. In its last 20 completed runs it > > > peaked at 40 jobs at once, and 12 of the 20 went over 20. I counted > only > > > jobs that got a runner, so queued jobs that were cancelled are not > > > included. In one successful PR run this morning, 30 jobs from 17 test > > > groups were running at the same time: > > > https://github.com/apache/airflow/actions/runs/37899638118 > > > > > > The cause is that ci-amd.yml calls many reusable workflows, and each > > > matrix sets max-parallel: 20 on its own. Each matrix stays under the > > limit, > > > but they run side by side and add up. GitHub has no setting that caps > the > > > whole workflow that I'm aware of. > > > > > > Thanks, > > > Justin > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
