Cancelling in-progress pull request workflows on push in GitHub Actions

A quick tip regarding GitHub Actions concurrency.

Sometimes iterating on a pull request yields quick subsequent pushes to a PR. In that case, multiple workflow runs may be started, which is wasteful and may have unintended consequences.

The corporation is strict on its use of resources. We want to ensure that pushing to a pull request cancels any in-progress CI workflows for that PR.

To achieve that we must:

Group the runs of a workflows for a PR
Cancel any in-progress runs for a group
Ensure that the above doesn’t happen on the default (main) branch

The two first points are covered by the GitHub documentation, but the latter is not.

Solution

We found a workaround on StackOverflow¹ for conditionally enabling cancel-in-progress. It’s achieved by giving every PR run a shared group based on the branch (ref), and every run on main a unique group id (run_id).

on:
  push:
    branches:
      - master
  pull_request:

concurrency:
  # Make sure every job on main has unique group id (run_id), so cancel-in-progress only affects PR's
  # https://stackoverflow.com/questions/74117321/if-condition-in-concurrency-in-gha
  group: ${{ github.workflow }}-${{ github.head_ref && github.ref || github.run_id }}
  cancel-in-progress: true

Pitfalls

What happens if cancel-in-progress is false?

There seems to be a widespread²^,³ sugestion to disable the cancellation on the default branch:

# Don't do this!
cancel-in-progress: ${{ github.ref_name != 'main' }}

Unfortunately, based on empirical evidence, that won’t work. The runs are not queued as one might expect ⁴. There can be at most one running and one pending job in a concurrency group at any time.

This means that even though cancel-in-progress set to false, the workflow may still be cancelled. For example, when there’s two concurrent runs in a group - one of which is pending - a new job will cancel the pending job, and take its place.