On Fri, Nov 04, 2022 at 02:46:23AM +0100, Ævar Arnfjörð Bjarmason wrote: > > This is particularly problematic in the case of Pull Requests where a > > single contributor can easily (inadvertently) prevent timely builds for > > other contributors. > > The "timely" being an issue in git/git and/or gitgitgadget where CI time > is a shared resource, but not in a <someuser>/git running CI just for > <someuser>? Yup, agreed. > > To help with this situation, let's use the `concurrency` feature of > > GitHub workflows, essentially canceling GitHub workflow runs that are > > obsoleted by more recent runs: > > https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency > > In my own fork I very much use this concurrency not-cancel-in-progress > intentionally. Interesting. I noted basically the opposite in my earlier reply[1] to Johannes, where the behavior I want is that newer pushes of the same topic supersede older ones that are currently in progress. But I think you make a compelling point (which doesn't match my own workflow, but I can see the utility of nonetheless). I was thinking that we could rely on something similar to the ci-config ref stuff from back in e76eec35540 (ci: allow per-branch config for GitHub Actions, 2020-05-07), but it looks like it'll be a little trickier than that, maybe impossible. We need to know about the state of the ci-config branch before we set the concurrency bits. So I think you *could* do something like: --- >8 --- diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 4fdf4d3552..f1ca364f96 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -2,11 +2,6 @@ name: CI on: [push, pull_request] -# Avoid unnecessary builds -concurrency: - group: ${{ github.workflow }}-${{ github.ref }} - cancel-in-progress: true - env: DEVELOPER: 1 @@ -39,7 +34,14 @@ jobs: then enabled=no fi + skip_concurrent=yes + if test -x config-repo/ci/config/skip-concurrent && + ! config-repo/ci/config/skip-concurrent '${{ github.ref }}' + then + skip_concurrent=no + fi echo "::set-output name=enabled::$enabled" + echo "::set-output name=skip_concurrent::$skip_concurrent" - name: skip if the commit or tree was already tested id: skip-if-redundant uses: actions/github-script@v3 @@ -86,6 +88,9 @@ jobs: name: win build needs: ci-config if: needs.ci-config.outputs.enabled == 'yes' + concurrency: + group: ${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: needs.ci-config.outputs.skip_concurrent = 'yes' runs-on: windows-latest steps: - uses: actions/checkout@v2 --- 8< --- ...and similar "concurrency" blocks in each of the other jobs to define the settings at the job level instead of at the workflow level. So, it's doable, but a little gross. At the very least, it would satisfy Ævar's workflow requirements, too, since he could write a script that exits with non-zero status to avoid the new behavior. Thanks, Taylor [1]: https://lore.kernel.org/git/Y2R0YrQzKaUZzaPB@nand.local/
