From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] ci: avoid unnecessary builds
Date: Fri, 04 Nov 2022 02:46:23 +0100 [thread overview]
Message-ID: <221104.86bkpnzdqi.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <pull.1404.git.1667482458622.gitgitgadget@gmail.com>
On Thu, Nov 03 2022, Johannes Schindelin via GitGitGadget wrote:
> 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?
next prev parent reply other threads:[~2022-11-04 1:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 13:34 [PATCH] ci: avoid unnecessary builds Johannes Schindelin via GitGitGadget
2022-11-04 1:46 ` Ævar Arnfjörð Bjarmason [this message]
2022-11-04 2:23 ` Taylor Blau
2022-11-04 3:20 ` Jeff King
2022-11-08 9:16 ` Johannes Schindelin
2022-11-09 14:00 ` Jeff King
2022-11-10 2:40 ` Taylor Blau
2022-11-04 2:09 ` Taylor Blau
2022-11-07 19:45 ` Derrick Stolee
2022-11-07 19:53 ` Taylor Blau
2022-11-07 20:08 ` Derrick Stolee
2022-11-07 21:03 ` Ævar Arnfjörð Bjarmason
2022-11-07 21:59 ` Derrick Stolee
2022-11-07 22:44 ` Taylor Blau
2022-11-08 8:18 ` Johannes Schindelin
2022-11-08 18:30 ` Taylor Blau
2022-11-07 22:56 ` Ævar Arnfjörð Bjarmason
2022-11-08 0:02 ` Derrick Stolee
2022-11-08 0:31 ` Junio C Hamano
2022-11-08 9:51 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=221104.86bkpnzdqi.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).