Workflow sharing concurrency group cancelled instead of pending

[m-gawinecki]

I have two workflows sharing concurrency group:

jobs:
  evaluate:
    runs-on: [ android-emulator ]
    concurrency: evaluation_emulator

and:

jobs:
  other_tests:
    runs-on: [ android-emulator ]
    concurrency: evaluation_emulator

The second job has been cancelled:

Canceling since a higher priority waiting request for 'evaluation_emulator' exists

despite the fact the documentation says default behavior is to put workflow in a pending state, not cancelling:

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.

Why this happens?

[david-at-reflexai]

I see the same problem. Can someone reply on this? It's been 10 months since the original message.

[alekssmg]

More than a year later and problem still persists. Can someone, please, take a look into it? It's obviously a bug.

[asbjornu]

I too was surprised to discover that jobs in the same concurrency group are canceled instead of waiting for an existing job within the group to finish. I can see why canceling is a desired behavior for some, but at least it should be made configurable.

I want to avoid running several jobs of a certain kind concurrently, but I would like them all to complete at one point; effectively putting each job within the same concurrency group in a single-line FIFO queue.

[BenedekFarkas]

Did you try setting cancel-in-progress: false? Note that at the moment there can be only one pending job, which will always be the latest one, so the previous pending jobs will still be cancelled.

[ecs-jnguyen]

Problem

Right now if I run 3 jobs about 5 seconds apart with the same concurrency group the following will happen:

Start Job 1:

• job 1: in progress

Start Job 2:

• job 1: in progress
• job 2: pending

Start Job 3:

• job 1: in progress
• job 2: cancelled because there's a newer job
• job 3: pending

Proposed Fix

I think there should be an additional setting cancel-pending that will default to true for backwards compatibility. Then we can set it to false so that runs each job in order instead of cancelling if there's a newer job.

For example, I'm using github actions with the workflow_dispatch event. All the jobs still need to run so adding a new one shouldn't cancel the other pending ones out.

[Granitosaurus]

at the moment there can be only one pending job, which will always be the latest one, so the previous pending jobs will still be cancelled.

Wish this was indicated somewhere as it took me forever to debug this - why would there be only 1 pending job slot?

One way to get around this limitation is to use self hosted runners with unique labels which forces hard concurrency instead:

Then lock each job to a specific runner:

jobs:
  deploy-1:
    runs-on: foo
  deploy-2:
    runs-on: bar
  deploy-3:
    runs-on: gaz

Now all jobs will queue infinitely waiting for the right actions worker to free up. Note that jobs.<job name>.timeout-minutes key can be used to control how long pending jobs will wait until timeout.