ci: avoid building from the same commit in parallel
commit99fe06cbfd660726b1601a4d36897ed90e5d5b64
authorJohannes Schindelin <Johannes.Schindelin@gmx.de>
Wed, 23 Aug 2023 08:42:45 +0000 (23 10:42 +0200)
committerJunio C Hamano <gitster@pobox.com>
Fri, 25 Aug 2023 16:48:22 +0000 (25 09:48 -0700)
tree654e05a12b18a4c7063bb336727db4fd47625ade
parentfb7d80edcae482f4fa5d4be0227dc3054734e5f3
ci: avoid building from the same commit in parallel

At times, we may need to push the same commit to multiple branches
in the same push.  Rewinding 'next' to rebuild on top of 'master'
soon after a release is such an occasion.  Making sure 'main' stays
in sync with 'master' to help those who expect that primary branch
of the project is named either of these is another.

We already use the branch name as a "concurrency group" key, but
that does not address the situation illustrated above.

Let's introduce another `concurrency` attribute, using the commit
hash as the concurrency group key, on the workflow run level, to
address this. This will hold any workflow run in the queued state
when there is already a workflow run targeting the same commit,
until that latter run completed. The `skip-if-redundant` check of
the second run will then have a chance to see whether the first
run succeeded.

The only caveat with this strategy is that only one workflow run
will be kept in the queued state by the `concurrency` feature: if
another run targeting the same commit is triggered, the
previously-queued run will be canceled. Considering the benefit,
this seems the smaller price to pay than to overload Git's build
agent pool with undesired workflow runs.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
.github/workflows/main.yml