[PATCH 14/20] CI: GitLab: Split build_world tasks

[Tom Rini]

On Wed, Jun 12, 2024 at 02:24:24PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 12 Jun 2024 at 11:07, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, Jun 12, 2024 at 05:14:46PM +0100, Jiaxun Yang wrote:
> > >
> > >
> > > 在2024年6月12日六月 下午5:01，Tom Rini写道：
> > > > On Tue, Jun 11, 2024 at 10:04:13PM +0100, Jiaxun Yang wrote:
> > > >
> > > >> Current build_world task runs for too long on public gitlab
> > > >> runner.
> > > >>
> > > >> Split the job as what we've done to azure pipeline.
> > > >>
> > > >> Signed-off-by: Jiaxun Yang <jiaxun.yang at flygoat.com>
> > > >> ---
> > > >>  .gitlab-ci.yml | 103 +++++++++++++++++++++++++++++++++------------------------
> > > >>  1 file changed, 59 insertions(+), 44 deletions(-)
> > > >
> > > > I don't like this. The list in Azure is because of the time limits there
> > > > and in turn we:
> > > > a) Have to tweak it periodically to keep things from running too long
> > > > b) Have to tweak it to ensure that we don't miss some new SoC/etc
> > >
> > > Then it will render running CI test on gitlab.com impossible again :-(
> >
> > Yeah, it's not something I'm the happiest with. Looking around a bit, I
> > see a blog post that talks about dealing with dynamic variables, in
> > Azure. So we could, I think, figure out some logic to have each build
> > stage say what platforms it covers. And then have a final step that
> > compares all of the platforms built vs the global list (just
> > tools/buildman/buildman --dry-run -v) to make sure nothing was missed.
> > With something like that, and assuming GitLab can do it too (it probably
> > can), I'm OK with having the world build be broken down to 10 groups
> > (maximum number of parallel jobs in Azure CI for free) since we'll know
> > if we miss something too.
> >
> > So lets set this patch (and the doc update) aside for now, unless you
> > want to look at the above. I'll look at the above soon.
> 
> Could we hook up one of our machines as a public runner somehow?

It's a pool of free runners, ala Azure. I don't think we can, no, and I
don't want to make all of our runners available on public CI either,
they're a bit over-whelmed as it is I think once custodians start
working.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240613/4aa725a3/attachment.sig>