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

[Junio C Hamano <gitster@pobox.com>]

"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.