[Kitsios Konstantinos (kitsiosk)]

Change Summary

Currently, if a PR is open and a push happens, the cli-ci 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 9b896ab triggered this workflow run, and shortly after the commit a28c769, that happened on top of the first commit, triggered this workflow. Both workflows ran till the end, spending approximately 5 CPU minutes each. With the proposed changes, the first run would be cancelled, hence saving ~5 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 1 CPU hours over the last few months.

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

[Kitsios Konstantinos (kitsiosk)]

@microsoft-github-policy-service agree

[Victor Vazquez (vhvb1989)]

thank you Kitsios Konstantinos (@kitsiosk)
Let's wait for Daniel Jurek (@danieljurek) and Wes Haggard (@weshaggard) review for this. I think is automatically handled by AzureDevOps for internal pipelines right? Or is there a way to do the same?

[Wes Haggard (weshaggard)]

Thanks for the contribution Kitsios Konstantinos (@kitsiosk). We haven't used this yet but I've just read the documentation https://docs.github.com/en/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/control-the-concurrency-of-workflows-and-jobs and I think this will be beneficial for us.

[Daniel Jurek (danieljurek)]

Victor Vazquez (@vhvb1989) -- Indeed Azure DevOps already does this by default: https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#draft-pr-validation

The autoCancel defaults to true (and we don't generally override that).