Re: [PATCH] ci: avoid unnecessary builds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> From: Johannes Schindelin <johannes.schindelin@xxxxxx>
>
> 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?




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux