>lun. 15 juin 2026 at 17:32, Ludovic Courtès <[email protected]> wrote:
> Hello! > > Cayetano Santos <[email protected]> skribis: > >> A bit of background. CI farm builds every single pull request (pr) >> which doesn’t impact more than 300 dependent¹: on success, the pr is >> merged in master ... and rebuild back again, consuming computing >> resources (see guix/guix!9274, for example). > > That’s not exactly true. Currently, pulls.ci.guix.gnu.org > (aka. @guix-cuirass-bot) has no limit and that’s a limitation that will > be addressed in Cuirass 1.4: > > https://codeberg.org/guix/cuirass/issues/30 > > In the meantime, I enforce a limit… by hand (canceling evaluations with > more than 1,000 builds or so). > > Note that pulls.ci currently runs on a single x86 machine with 92 cores: > > https://codeberg.org/guix/maintenance/pulls/49 > > It’s becoming insufficient, but it’s also rather frugal. :-) I was not referring here to CI infrastructure itself, but rather to the Guix manual, trying to provide some context: 300 is the limit between sending to master or to a topic branch, that’s all. My reflexion rather goes to the inefficiency of building twice the same pull request, once by the @guix-cuirass-bot, then when it lands on master, regardless of hardware considerations. That’s the way it is, and I’m fine with that. But given this fact, maybe decreasing the ratio of the individual pr directly built by CI is the way to go. >> Beyond the current 300 threshold, a pr should be send to a topic >> (team) branch; once every few, all the branch is built, all of its pr >> in a raw. On success, the branch is merged in master: available >> binaries are then available as substitutes, no extra computing >> resources are used². >> >> Teams, branches and Guix QA³ are a great idea, and way more computing >> efficient than processing individual pr. This is why I’m proposing >> here a slightly different strategy to alter the fraction of changes >> which fall into each category (see guix/guix!9314). >> >> - Reduce the current threshold from 300 to 150 dependents > The problem is that there’s a lot of friction involved with topic > branches: one needs to get a committer to actually create the branch, > someone must email [email protected] (despite it being officially > turned off in January 2026), optionally get someone to set up a jobset > on ci.guix, monitor qa.guix.gnu.org to find out when the topic branch is > next in line for merging, and finally get a committer to merge it. But here you’re describing how things are now, right ? My proposal doesn’t change anything to our current workflow. It only brings more pr to branches, instead of merging them directly on master, which I find more computing efficient. > I think we should work to streamline this process, at least by getting > guix-patches out of the loop. Sure, regardless of this proposal. C.
signature.asc
Description: PGP signature
