Cancel previous workflow runs on newer refs

[aaemnnosttv]

Feature Description

Our GitHub Action workflows currently run until completed or fail for every commit they are triggered by.

In most cases however, it is usually undesirable for a workflow to continue running once another workflow for the same branch has started. In some cases, this can even cause a race condition where git-based deploy jobs fail due to upstream changes cause a push to fail. This can result in deployed assets not reflecting the latest state for their respective PR/branch or cause deployed artifacts to be left in the target repo longer than they should be due to a similar conflict in the prune/remove workflow job.

Travis has similar functionality available to automatically cancel builds for a branch/PR when a newer commit is pushed as it essentially "invalidates" the previous run. There's little benefit in letting the jobs finish as we have a limited number of concurrent jobs that can run. This is only manageable via the settings for the repository for Travis, but we should enable these as well:

For GitHub Actions, we can leverage the cancel-workflow-action to get similar behavior for our actions. (It's not quite as good as Travis' as it requires the job to run which in turn requires availability in the queue)

This (in combination with the settings above for Travis and the recently added fast_finish configuration) will help us to run our builds as efficiently as possible within our limits for maximum concurrent jobs/builds.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• GitHub Action workflows for queued/pending, or in progress runs should be automatically cancelled when a newer commit is pushed to the same branch

Implementation Brief

• Merge Add auto-cancellation workflow #2361

QA Brief

• Review the Actions log for the repository
• Check workflows for VRT, Plugin Zips, and Storybook to verify cancelled workflows are present (shown by the gray octagon with ❕ inside) - e.g.
  

Changelog entry

• N/A

[felixarntz]

IB ✅

[felixarntz]

@aaemnnosttv Not high priority to finish within this sprint, but since you already implemented it, and if this is good to go, we can just add Sprint 36 to it.

[aaemnnosttv]

👍 – there's one caveat to this which I read about when looking into this before which is that since the cancellation is triggered by your own workflow it won't work until that job runs; it sounds more obvious that it might seem if you're coming from another CI provider. Travis cancels all older job runs automatically, whereas this would potentially wait in the queue of other jobs (depending on our max concurrent job limit) before it could run and trigger others to be cancelled. It's not ideal, but better than nothing given the current options available with GHA.

Edit: apparently there is a decent workaround with the advanced usage if you know the workflow IDs, which we do 👍

[aaemnnosttv]

@felixarntz I tweaked the ACs here to be more accurate to the desired outcome and less specific to the implementation which is slightly different now. Should be ready for review now 👍

[asvinb]

VRT Test:

Cancelled workflow present ✔️

Plugin Zip:

Cancelled workflow present ✔️

Storybook:

Cancelled workflow present ✔️

QA: ✅