git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] ci: avoid unnecessary builds

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 8, 2022, 00:31 UTC
Message-ID
<xmqqk046cmmv.fsf@gitster.g>
In-Reply-To
<f975f57e-71e2-3227-8039-14dff82f04db@github.com>
Derrick Stolee <derrickstolee@github.com> writes:
Show 19 quoted lines
> 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.

Previous: Derrick StoleeNext: Johannes Schindelin
Message 19 of 20 in “ci: avoid unnecessary builds”
  1. ci: avoid unnecessary buildsJohannes Schindelin via GitGitGadget, Nov 3, 2022
  2. Ævar Arnfjörð BjarmasonNov 4, 2022
  3. Taylor BlauNov 4, 2022
  4. Jeff KingNov 4, 2022
  5. Johannes SchindelinNov 8, 2022
  6. Jeff KingNov 9, 2022
  7. Taylor BlauNov 10, 2022
  8. Taylor BlauNov 4, 2022
  9. Derrick StoleeNov 7, 2022
  10. Taylor BlauNov 7, 2022
  11. Derrick StoleeNov 7, 2022
  12. Ævar Arnfjörð BjarmasonNov 7, 2022
  13. Derrick StoleeNov 7, 2022
  14. Taylor BlauNov 7, 2022
  15. Johannes SchindelinNov 8, 2022
  16. Taylor BlauNov 8, 2022
  17. Ævar Arnfjörð BjarmasonNov 7, 2022
  18. Derrick StoleeNov 8, 2022
  19. Junio C HamanoNov 8, 2022
  20. Johannes SchindelinNov 8, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.