[PATCH] ci: cancel stale pull request workflow runs

[PATCH] ci: cancel stale pull request workflow runs

[Harald Nordgren via GitGitGadget]

From: Harald Nordgren <haraldnordgren@gmail.com>

The CI workflow groups runs by commit hash, so every push to a pull
request starts a separate workflow run. Group pull request runs by pull
request number and cancel runs superseded by a newer push, while keeping
push events grouped by commit hash for the skip-if-redundant behavior.

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
    ci: cancel stale pull request workflow runs
    
    Group CI workflow runs by pull request and cancel older revisions so
    only the latest push consumes runner capacity.

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2369%2FHaraldNordgren%2Fcancel-stale-pr-ci-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2369/HaraldNordgren/cancel-stale-pr-ci-v1
Pull-Request: https://github.com/git/git/pull/2369

 .github/workflows/main.yml | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 85cfedf5b0..1dc4ca121c 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -5,18 +5,20 @@ on: [push, pull_request]
 env:
   DEVELOPER: 1
 
-# If more than one workflow run is triggered for the very same commit hash
-# (which happens when multiple branches pointing to the same commit), only
-# the first one is allowed to run, the second will be kept in the "queued"
-# state. This allows a successful completion of the first run to be reused
-# in the second run via the `skip-if-redundant` logic in the `config` job.
+# For pull requests, only the latest workflow run is allowed to proceed.
+# Older runs are canceled when a new revision is pushed.
 #
-# The only caveat is that if a workflow run is triggered for the same commit
-# hash that another run is already being held, that latter run will be
-# canceled. For more details about the `concurrency` attribute, see:
+# For pushes, if more than one workflow run is triggered for the very same
+# commit hash (which happens when multiple branches point to the same commit),
+# only the first one is allowed to run. This allows a successful completion of
+# the first run to be reused in the second run via the `skip-if-redundant`
+# logic in the `config` job.
+#
+# For more details about the `concurrency` attribute, see:
 # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
 concurrency:
-  group: ${{ github.sha }}
+  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}
+  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
 
 jobs:
   ci-config:

base-commit: a97fcc37c2bc6340a8d7ce78dedf227aac4e9aa7
-- 
gitgitgadget

Re: [PATCH] ci: cancel stale pull request workflow runs

[Harald Nordgren]

Hi!

It would be nice to get some review here, this will save a lot of CI money.


Harald

Re: [PATCH] ci: cancel stale pull request workflow runs

[Junio C Hamano]

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

Nobody seems interested in reviewing this patch, and I am not
happy leaving too many topics in the "Needs review" state.  So
here is my attempt to think aloud, based primarily on what I read
in the proposed commit log message.  Consider any misunderstanding
on my part a sign that the proposed log message is lacking.

> -  group: ${{ github.sha }}
> +  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.sha }}
> +  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

We used to assign each commit to its own group.  For a pull-request
event, the new configuration instead assigns it to the concurrency
group <workflow>-<pull-request-number> (e.g., "main-workflow-42"),
so if you are impatient and update an existing pull request before
the CI working on it finishes, the new request will be placed in the
same group.

For other events, <workflow>-<commit-object-name> is the group used
for the commit, which differs from the original behavior, but
arguably in a good way.  If three or more workflows sharing the same
concurrency group are triggered at the same time for the same
commit, because there will be at most one active run and one pending
run in the same group, we may see some workflows fail to run on the
commit.

  NOTE NOTE NOTE: The previous paragraph is based on my incomplete
  understanding of how GitHub Actions works, gathered from skimming
  the documentation.  It needs to be verified, and if correct, it
  should be added to the commit log message.  If it is not correct,
  a revised description discussing how this change does NOT affect
  non-PR events negatively should be included in the commit log
  message instead.

The original configuration did not specify 'cancel-in-progress' at
all, so these jobs did not cancel each other.  Now, for pull-request
events, an earlier run in the same group is canceled when another
one is triggered.  If you are impatient and update an existing pull
request before the CI working on it finishes, the new request will
cancel the currently running one and replace it.  

For non pull-request events, it is as if no 'cancel-in-progress'
were specified, as it defaults to false, so there is no regression
there.  We _might_ want to have two pushes back to back that causes
the CI work on the same commit to drop one of them, but that can be
left out as an independent issue.

Thanks.