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

[Simon Glass]

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?

Regards,
Simon