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 used to use the branch name as the "concurrency group" key, but
by switching to use the commit object name would make sure the
builds for the same commit would happen serially, and by the time
the second job becomes ready to run, the first job's outcome would
be available and mking it unnecessary to run the second job.
Helped-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
* There are tons of concurrency groups defined, but as a trial
change, here is to cover the "regular" matrix that consumes the
most resources (linux-asan-ubsan is the worst culprit, it seems).
.github/workflows/main.yml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 30492eacdd..27b151aadf 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -240,8 +240,7 @@ jobs:
needs: ci-config
if: needs.ci-config.outputs.enabled == 'yes'
concurrency:
- group: ${{ matrix.vector.jobname }}-${{ matrix.vector.pool }}-${{ github.ref }}
- cancel-in-progress: ${{ needs.ci-config.outputs.skip_concurrent == 'yes' }}
+ group: ${{ matrix.vector.jobname }}-${{ matrix.vector.pool }}-${{ github.sha }}
strategy:
fail-fast: false
matrix:
--
2.42.0
