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

[Tom Rini]

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.

-- 
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/20240612/0b46b722/attachment.sig>