> 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] > >
