Re: [PATCH] ci: avoid unnecessary builds

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 4, 2022, 01:46 UTC
Message-ID: <221104.86bkpnzdqi.gmgdl@evledraar.gmail.com>
In-Reply-To: <pull.1404.git.1667482458622.gitgitgadget@gmail.com>

On Thu, Nov 03 2022, Johannes Schindelin via GitGitGadget wrote:

Show 12 quoted lines

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Whenever a branch is pushed to a repository which has GitHub Actions
> enabled, a bunch of new workflow runs are started.
>
> We sometimes see contributors push multiple branch updates in rapid
> succession, which in conjunction with the impressive time swallowed by
> even just a single CI build frequently leads to many queued-up runs.
>
> 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>?

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

I.e. I'll run local tests, but also occasionally push to CI (particularly when I know I have bad local coverage).

But that's very much an async process, sometimes I'll look at the (hopefully finished by then) CI in the morning.

E.g. now I have a re-pushed branch where the last tip it was at is still running CI, but it's waiting just the ASAN job.

Having that breadcrumb trail of "green" CI is very helpful, i.e. push every hour or so with something WIP, and be able to eventually see when things went wrong, if they went wrong.

We have CI config for other such stuff, but I think it's probably hard to use in this case, as this involves cancelling the *other* job, not cancelling ourselves. So by the time we're past the config stage is when we might want to cancel.

But doesn't this support the "if" syntax to narrow this down to the relevant repos where this would help, while leaving those forks where it isn't an issue to enact their own policy?