ci(workflows): cancel in progress workflows on new trigger

[y3rsh]

Overview

Given I push, make a PR, or merge a PR
When a workflow "on" condition is matched
Then the workflow will queue to run
But already running workflows from the same trigger, that may now be redundant, continue running

I make a PR but immediately see a typo so I fix it and push. All the triggered workflows from my PR creation keep running but don't need to, I only want the workflows running against my new commit to run.

GitHub Workflow Concurrency Documentation

Review requests

Questions

• Are there exceptions to this where we don't want to cancel previously running workflows?
  • On a merge to edge, if a subsequent merge to edge happens before the workflows to build finish, they will be cancelled. This results in states of the edge branch with no built assets. Do we want to make an exceptions for edge?
  • Scenarios with the release* branches where this may have side effects?
  • Side effects from re-running a workflow?
• Other considerations?
• Instead of doing this in all workflows, pick a couple to prove the concurrency group is restrictive enough?

Risk assessment

Medium, this needs 👀 as it is hard to map all the workflows and triggers conceptually to understand any side effects.

[codecov]

Codecov Report

Merging #11370 (6bfb16c) into edge (d45a2d4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             edge   #11370   +/-   ##
=======================================
  Coverage   74.74%   74.74%           
=======================================
  Files        2046     2046           
  Lines       56966    56966           
  Branches     5545     5545           
=======================================
  Hits        42580    42580           
  Misses      13128    13128           
  Partials     1258     1258           

Flag	Coverage Δ
app	75.28% <ø> (ø)
components	53.05% <ø> (ø)
g-code-testing	97.13% <ø> (ø)
hardware	59.95% <ø> (ø)
labware-library	49.74% <ø> (ø)
protocol-designer	45.81% <ø> (ø)
react-api-client	82.98% <ø> (ø)
shared-data	86.08% <ø> (ø)
step-generation	88.39% <ø> (ø)
update-server	73.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[sfoster1]

I like these changes for devs but we should definitely not apply them to tag builds and probably edge builds. i think we should apply them to release-branch builds because the "oh god i made a typo" thing is extremely common in, for instance, release-branch bump commits.

[y3rsh]

I like these changes for devs but we should definitely not apply them to tag builds and probably edge builds. i think we should apply them to release-branch builds because the "oh god i made a typo" thing is extremely common in, for instance, release-branch bump commits.

Makes sense. I have added expressions to detect when the branch name is edge and for any push of a tag. When these are detected, the github.run_id is added to the concurrency group string. The only time a github.run_id would stay the same between runs is on a re-run. If you somehow started 2 re-runs one after another (which doesn't seem possible) a cancellation on an edge or tag triggered workflow run might happen.

I proved the expressions out in this repo

[SyntaxColoring]

I like these changes for devs but we should definitely not apply them to tag builds

Just curious: why don't we want to auto-cancel tag builds?

[sfoster1]

I like these changes for devs but we should definitely not apply them to tag builds

Just curious: why don't we want to auto-cancel tag builds?

Everything about nonstandard or surprising aspects of release management should be manual, in my opinion. It's fine and a good idea to automate happy paths, but anything that gets weird really needs human oversight.

[sfoster1]

Looks good to me!