Git Mailing List Archive mirror
 help / color / mirror / Atom feed
From: Derrick Stolee <>
To: "Ævar Arnfjörð Bjarmason" <>
Cc: Taylor Blau <>,
	Johannes Schindelin via GitGitGadget <>,,
	Johannes Schindelin <>
Subject: Re: [PATCH] ci: avoid unnecessary builds
Date: Mon, 7 Nov 2022 19:02:01 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 11/7/2022 5:56 PM, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Nov 07 2022, Derrick Stolee wrote:
>> On 11/7/22 4:03 PM, Ævar Arnfjörð Bjarmason wrote:
>>> On Mon, Nov 07 2022, Derrick Stolee wrote:

>>>> Either of these points may have an incorrect assumption, so
>>>> I'm prepared to be wrong.
>>> I *think* you're wrong about #2, but I'm not sure either.
>> At the very least, the configurable option requires fetching the
>> repo and checking out at least one file. I don't know how much it
>> actually saves one way or another.
> It's already fetching the ci-config repo, so we're talking about the
> marginal cost of running the bit of shellscript to check if
> config-repo/ci/config/skip-concurrent is executable, and if not keeping
> the default config.

>> I wonder how we could determine this. Should we run a few CI
>> jobs with some force-pushes in either approach (config turned
>> off) so we know that cost?
> The incremental cost of that "test -x", or...? I'm not sure what you
> mean here.

The difference is that setting the concurrency globally allows
Actions to decide the concurrency from the workflow file alone,
before any jobs are run. This is done without a clone.

The method introduced in e76eec35540 (ci: allow per-branch config
for GitHub Actions, 2020-05-07) requires running the ci-config
job at minimum to set the concurrency value, which involves doing
a (very small, shallow) clone of the ci-config branch to determine
if that file exists.

Since this is the first job to run in the workflow, the global
concurrency will only reduces the amount of compute consumed
when pushes happen close together, but that is included for "oops
I forgot to --amend" and other common cases.

At the very least, the difference between the two mechanisms is
greater than a 'test -x'.


  reply	other threads:[~2022-11-08  0:02 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
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 [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

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