Description
Yesterday we observed enormous delays and queuing of GH Action pipelines.
The underlying issue was probably network hiccups, still, it took more than 6 hours to recover (timing out most of the queued jobs).
The current setup is optimized for CI speed but is clogging the available concurrent runners.
in the "testing phase", after the build of the distribution, we count 7 independent jobs + 12 matrix jobs, given that the available runners on a Free plan are 20 ( ref ) it means that this project CI is (on average) serving 1/2 PRs concurrently, queuing all the rest of the jobs.
I think that an acceptable compromise is to slow the CI down by removing one axis from the matrix build but allowing more PR CIs to progress concurrently.
Discussion
No response
Motivation
No response
Details
No response
Description
Yesterday we observed enormous delays and queuing of GH Action pipelines.
The underlying issue was probably network hiccups, still, it took more than 6 hours to recover (timing out most of the queued jobs).
The current setup is optimized for CI speed but is clogging the available concurrent runners.
in the "testing phase", after the build of the distribution, we count 7 independent jobs + 12 matrix jobs, given that the available runners on a Free plan are 20 ( ref ) it means that this project CI is (on average) serving 1/2 PRs concurrently, queuing all the rest of the jobs.
I think that an acceptable compromise is to slow the CI down by removing one axis from the matrix build but allowing more PR CIs to progress concurrently.
Discussion
No response
Motivation
No response
Details
No response