Skip to content

Commit 99fe06c

Browse files
dschogitster
authored andcommitted
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
1 parent fb7d80e commit 99fe06c

File tree

1 file changed

+13
-0
lines changed

1 file changed

+13
-0
lines changed

.github/workflows/main.yml

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,19 @@ on: [push, pull_request]
55
env:
66
DEVELOPER: 1
77

8+
# If more than one workflow run is triggered for the very same commit hash
9+
# (which happens when multiple branches pointing to the same commit), only
10+
# the first one is allowed to run, the second will be kept in the "queued"
11+
# state. This allows a successful completion of the first run to be reused
12+
# in the second run via the `skip-if-redundant` logic in the `config` job.
13+
#
14+
# The only caveat is that if a workflow run is triggered for the same commit
15+
# hash that another run is already being held, that latter run will be
16+
# canceled. For more details about the `concurrency` attribute, see:
17+
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
18+
concurrency:
19+
group: ${{ github.sha }}
20+
821
jobs:
922
ci-config:
1023
name: config

0 commit comments

Comments
 (0)