GitHub Actions workflows are most often not running [bug]

[danlester]

Describe the bug

OK we need to revisit the concurrency groups for our actions - most are being canceled.

I think each yaml workflow file needs a different group - maybe ${{ github.ref }}. The aim for us adding these groups was (presumably) so that subsequent pushes to a branch cancel existing runs to save resources, but jobs are being canceled within the same push.

The reason is here: https://github.saobby.my.eu.orgmunity/t/concurrency-doesnt-work-as-expected/192205

[magsol]

This seems like the key post https://github.saobby.my.eu.orgmunity/t/concurrency-doesnt-work-as-expected/192205/6

Official documentation on concurrency groups reads as

When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending.
Any previously pending job or workflow in the concurrency group will be canceled.
To also cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true`.

Translation:

The key is:

• Job A arrives, finds nothing in its concurrency group and runs
• Job B arrives, finds job A running in its concurrency group, looks for anyone else waiting (with the intent to kill them), finds nothing, and waits.
• Job C arrives, finds job A running in its concurrency group looks for anyone else waiting (with the intent to kill them), finds job B, kills it, and waits.
• Job A finishes, job C is started.

With flag:

• Job A arrives, finds nothing in its concurrency group and runs
• Job B arrives, finds job A running in its concurrency group, has the flag to kill a running instance, kills A, and starts to run.

It isn’t a queue, there’s a single waiting slot, it’s either empty or occupied.

A new job can either shoot a running job or the parked job.

Is it just me or is that not at all intuitive?

[danlester]

These didn't need to be completely removed. This is what I suggested:

I think each yaml workflow file needs a different group - maybe <test name>${{ github.ref }}

So, test.yaml might have concurrency group test-${{ github.ref }} whereas docs.yaml might have group docs-${{ github.ref }}.

That way, a new push of the same ref would cancel any running jobs in each group and start the latest instead. This would save resources.

But the problem with the old method (every workflow having the same group) was that let's say docs.yaml was run first by GitHub, then test.yaml queued immediately after, GitHub would cancel the docs run in favor of the test run for the very same ref... But of course for one ref you actually want to run both docs and test.