matrix: limit to only concurrent 5 jobs

[glimchb]

this allows more fairness between workflows

[tomzawadzki]

I'm not against the change, but what is the expected benefit ?

Every job in workflow has to finish before posting a vote, this change is allowing more parallel workflow runs - but each one will take longer. For example under load, the per-patch tests would still take up all the runners and more instances of per-patch workflows would compete against each other for runners. Meanwhile if not under load, the per-patch would just take longer.

In the past I was looking at limiting the number of parallel per-patch workflows or leaving some runners for other workflows, hoping that concurrency groups would be helpful. Unfortunately from my understanding applying them to per-patch might result in dropping queued up workflow runs if one already exists.
On the other hand it might be useful if we use Gerrit patch id as concurrency group - canceling previous run if new patch set was pushed.

[karlatec]

I'm not against the change, but what is the expected benefit ?

I was actually thinking the same thing, but ultimately didn't comment.

Limiting to only just 5 concurrent jobs gives other builds a chance to at least start doing something instead of waiting in queue (I think right now we have so many jobs ran by a single workflow run that it hogs up all of the runners? Or very close to that.).

IMO this change is not needed, but feel free to proceed.

Meanwhile if not under load,

Yeah, I feel like recently this doesn't happen :P