[CI]: Cancel CI runs that become obsolete

[kitsiosk]

About the changes

Currently, if a PR is open and a push happens, the e2e:frontend workflow will start running. If, shortly after a subsequent push on the same PR happens, the workflow will start running again without cancelling the previous (now obsolete) run. With these changes, the first run would be cancelled, thus saving compute resources (see below for quantity) that can be used to speed up your overall CI/CD, without sacrificing functionality, since the second run will contain the changes from the first push as well. 🌱

Example

Here is an example of the behaviour described above: the commit b1b2e61 triggered this workflow run, and shortly after the commit 9997fe1, that happened on top of the first commit, triggered this workflow. Both workflows ran till the end, spending approximately 8 CPU minutes each. With the proposed changes, the first run would be cancelled, hence saving ~8 CPU minutes and clearing the queue for other workflows. Note that this is an example of a single concurrent run; the accumulated gain for all PRs would be higher, with a lower estimate at 2 CPU hours over the last few months.

The same holds for these workflow(s) as well: Dependency review, PR -> Build Docs.

Context

Hi,

We are a team of researchers from University of Zurich and we are currently working on energy optimizations in GitHub Actions workflows.

Kindly let us know (here or in the email below) if you would like more details, if you want to reject the proposed changes for other reasons, or if you have any question whatsoever.

Best regards,
Konstantinos Kitsios
konstantinos.kitsios@uzh.ch

[vercel]

@kitsiosk is attempting to deploy a commit to the unleash-team Team on Vercel.

A member of the Team first needs to authorize it.

[Copilot]

Pull Request Overview

This PR introduces a concurrency setting in several GitHub Actions workflows to automatically cancel outdated runs on the same pull request, reducing wasteful compute time.

• Added a concurrency block to cancel in-progress runs when a new event on the same PR triggers.
• Updated three workflow files: e2e.frontend.yaml, dependency-review.yml, and build_doc_prs.yaml.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
.github/workflows/e2e.frontend.yaml	Add concurrency block to cancel previous PR workflow runs
.github/workflows/dependency-review.yml	Add concurrency block to cancel previous PR workflow runs
.github/workflows/build_doc_prs.yaml	Add concurrency block to cancel previous PR workflow runs

Comments suppressed due to low confidence (3)

.github/workflows/e2e.frontend.yaml:7

• [nitpick] The same concurrency block is repeated in multiple workflows. Consider creating a reusable workflow or using YAML anchors to DRY up these configurations for easier maintenance.

concurrency:

.github/workflows/dependency-review.yml:7

• [nitpick] The same concurrency block is repeated in multiple workflows. Consider creating a reusable workflow or using YAML anchors to DRY up these configurations for easier maintenance.

concurrency:

.github/workflows/build_doc_prs.yaml:9

• [nitpick] The same concurrency block is repeated in multiple workflows. Consider creating a reusable workflow or using YAML anchors to DRY up these configurations for easier maintenance.

concurrency:

[coveralls]

coverage: 91.399% (-0.02%) from 91.415%
when pulling 7e40b8c on kitsiosk:cancel-duplicate-ci-runs
into e27bd74 on Unleash:main.

[nunogois]

Hey @kitsiosk, thank you so much for your contribution! It's truly appreciated.

As I'm reviewing this, I'm curious why you chose to group by PR number instead of using github.ref, for example. I assume it's because we only care about per-PR grouping here, but grouping by ref could give us cancels in other scenarios where it might be useful. I'd really appreciate any insight you have about this.

Thanks again!

[kitsiosk]

Hey @nunogois,

Thanks a lot for your review!

I assume it's because we only care about per-PR grouping here, but grouping by ref could give us cancels in other scenarios where it might be useful

Exactly, this is the reason; by default we target only PRs, since some project do not want to cancel concurrent runs on the same branch: cppcheck-opensource/cppcheck#7636 (comment)

If you prefer going for a per-branch approach, I'd be happy to do it.

[nunogois]

Hey @nunogois,

Thanks a lot for your review!

I assume it's because we only care about per-PR grouping here, but grouping by ref could give us cancels in other scenarios where it might be useful

Exactly, this is the reason; by default we target only PRs, since some project do not want to cancel concurrent runs on the same branch: danmar/cppcheck#7636 (comment)

If you prefer going for a per-branch approach, I'd be happy to do it.

Hi @kitsiosk,

Thank you for clarifying. I think this is perfect for now, and we can adjust as necessary.

Thank you again for your contribution!