On 10/16/26 13:07, Arnout Engelen wrote:
From: Kevin Liu <[email protected]>
[...]
What's happening right now: A single user opened a batch of about 17 PRs
on a single project, apache/grails-core, around 13:07 UTC today. Each PR's
CI run is using 25–47 jobs at once. Together they hold 569 of the 576
ubuntu-24.04 runners in use across the org.
I haven't checked myself, but I heard that when you open a PR from your own
fork instead of from a branch in the apache org, it gets the runners from
your own (free) budget instead of from the ASF's runner pool. If I'm seeing
it correctly, the 17 PRs in question are indeed coming from branches under
the apache org. Can anyone confirm my understanding? If that's indeed the
case, should we be recommending committers to create PRs from their own
forks rather than from branches under the apache org more actively?
if you open a PR the on-PR run is taken from the project, not the user.
That would not have been of help for this situation
[...]
Can you reach out to grails-core about capping matrix concurrency
(strategy.max-parallel:
15 or less)?
max-parallel will not help, there is no "big" matrix run. Instead there
are many concurrent workflows that have a small matrix
My suggestion:
make a expensive-pr-workflow, that starts all the heavy duty workflows
(all that are not done in a couple of minutes). This workflow will start
the heavy workflows in parallel, but also will have
concurrency:
group: expensive-pr-ci
queue: max
Which means expensive-pr-workflow will run only one at a time. For 17
PRs that means one PR after the other will be run instead of all at
once. queue: max allows a queue of up to 100. Or use this in all heavy
workflows directly, which effectively serializes them.. though then 100
is not 100 PRs anymore and given the amount or parallel workflows
grails-core has a second PR done shortly after the first may already get
into trouble and its workflows not starting.
bye Jochen
