From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <derrickstolee@github.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] ci: avoid unnecessary builds
Date: Mon, 07 Nov 2022 16:31:36 -0800 [thread overview]
Message-ID: <xmqqk046cmmv.fsf@gitster.g> (raw)
In-Reply-To: <f975f57e-71e2-3227-8039-14dff82f04db@github.com> (Derrick Stolee's message of "Mon, 7 Nov 2022 14:45:24 -0500")
Derrick Stolee <derrickstolee@github.com> writes:
> On 11/3/22 9:34 AM, 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.
>
> As someone who is both the cause and the victim of this, I
> thank you for finding a way to reduce wasted CPU time. This
> patch looks good to me, though I'll need to trust the docs
> and your testing to be sure it will work. We will definitely
> see it in place as it merges into 'next' and 'main'.
When I see breakages of 'seen' only at the CI, perhaps because it
manifests only on macOS, I manually "bisected" by pushing various
combinations of topics merged on top of 'master' and pushing the
result out as 'seen' only to the GitHub repository, and not having
to wait one to finish before pushing out another was a really nice
feature. Of course, I could wait before pushing another out, but
after seeing the last one close to successful completion in a few
minutes and being able to push out the next one was a great
timesaver, not only for the "few minutes", but for the countless
minutes because I will have to concentrate on more than just a "few
minutes" on another task if I have to switch to another task in
order to wait for just a "few minutes" before pushing the trial
merge out.
So, that is the only concern I have with this change, but in
general, not running jobs whose results are clearly not needed is a
good idea. It just is "clearly" is hard to determine automatically.
next prev parent reply other threads:[~2022-11-08 0:31 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
2022-11-08 0:31 ` Junio C Hamano [this message]
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=xmqqk046cmmv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=derrickstolee@github.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).