Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag

From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@gmail.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v2 RFC] support/scripts: don't build board defconfigs with Gitlab's pipelines trigged on tag
Date: Thu, 11 Nov 2021 14:55:10 +0100	[thread overview]
Message-ID: <20211111145510.57fc4222@windsurf> (raw)
In-Reply-To: <20211111101556.GC2504300@scaer>

Hello,

On Thu, 11 Nov 2021 11:15:56 +0100
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> > I hadn't had the chance to chime in on this one,  
> 
> Sorry, I could have waited a bit more indeed...

No, no, I think it's good that code gets reviewed and merged quickly.
We can't wait on every patch for everyone's opinion, otherwise the
project wouldn't move at all. So I really have absolutely nothing
against the fact of merging patches quickly.

> Again, agreed on principle.
> 
> But as Romain explained, that creates too much jobs when a tag is cut,
> so much so that a lot of them do not even stand a chance to even start.
> 
> In that case, the CI is not usefull at all either.
> 
> On the other hand, the defconfigs are already built reasonably often,
> every week, with a scheduled pipeline. It is thus pretty quick to notice
> a build failure.

True.

> So, my opinion is that I prefer a partial CI that is stable and
> dependable, where each failure is an actual failure, rather than a
> full-range CI that has a very low SNR, where people eventually stop
> caring about failure reports because they are often spurious failures.
> 
> Of course, we can reverse course on that commit; after all, that's what
> git-revert is for! ;-)
> 
> The better course of action, obviously, would be to have an infra that
> is strong enough to absorb all that load when we push a tag, but that's
> an order of magnitude more complex to achieve.

Indeed, I think we both agree that we should ideally be able to build
defconfigs every time a tag is pushed, and it's only a
practical/pragmatic reason that leads us to not do that. Fair enough.

> One thing, though: maybe some of the runners could be configured to
> accept more jobs at once, so even if each job then takes longer to run,
> we start them faster and thus do not hit the 24-hour blockage limit.

Things get really really slow if you build too many jobs in parallel,
as the runners start swapping like crazy.

So all in all, I'd say Romain's patch is OK, even though I wish we
could do better. That being said, when the tag is pushed it's a bit too
"late" to fixup defconfigs: they should ideally build properly *before*
a tag is created/pushed.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot