Concurrency: cancel-in-progress at top level doesn't seem to cancel running workflows?

[ocean90]

Hi there, I just tried the new shipped concurrency feature (thanks for that!) and with the following workflow in a private repo:

name: Deploy
on:

push:

branches:

- master

- production

paths-ignore:

- '**.md'
Ensures that only one deploy task per branch/environment will run at a time.
concurrency:

group: environment-${{ github.ref }}

cancel-in-progress: true
jobs:
deploy:

name: Deploy

runs-on: ubuntu-latest
steps:
   # All the steps

Then I did two pushes, both triggered the workflow but the second one didn’t cancel the first, instead it was pending and waiting for the first one to finish.
From the documentation it’s not clear, whether cancel-in-progress is actually supported on the top-level concurrency key. Both sections (this and this) only mention “in-progress job or run” and not “workflow”. Does somebody know whether this is supported or not? Maybe this is some sort of a copy/paste error?

Thanks!

[Simran-B]

The first link is about the concurrency key at the top level:

To also cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true.

It sounds like it should cancel pending as well as running workflows with the same group. If it doesn’t work then that might be a bug (remember that the feature is in beta).

[ocean90]

So far I was only able to get it to work when using cancel-in-progress at the job level.

[Simran-B]

There’s a remark about jobs.<job_id>.concurrency:

Note: When concurrency is specified at the job level, order is not guaranteed for jobs or runs that queue within 5 minutes of each other.

I wonder if this is related to your issue. Does it mean that a later queued job or workflow run may get canceled instead of the earlier queued one? But in your case neither is canceled…

[eseay]

@ocean90 I was very eager to utilize this feature when I saw the announcement, but I have had the same experience as you.

I inferred from the documentation that concurrency can be specified at the top level of the workflow just as you have (as well as at the job level, which I don’t presently have a use for).

I am using ${{ github.workflow }}-${{ github.ref }} as my concurrency key because I have multiple workflows that respond to the push event on some of these branches.

name: Create Alpha Build
on:
  push:
    branches: 
      - develop
      - release/*
       - '!release/**-rc*'
     tags: v2021.*
concurrency:

group: ${{ github.workflow }}-${{ github.ref }}

cancel-in-progress: true
.....

[ocean90]

Simran-B:

I wonder if this is related to your issue.

This should only apply if you use the key on the job level which I didn’t when I reported the issue. I wasn’t able to trigger this issue now with using concurrency on the job level either though.

Another bug was mentioned in Actions concurrency bug report but I’m not sure if they are related, maybe @yaananth can answer that?

[ocean90]

@yaananth gave an update in Actions concurrency bug report - #4 by yaananth for a related issue and so I tried the concurrency key on the workflow level again and it’s now working too!