[PATCH 0/9] Enable arm64 host support in Gitlab

[Tom Rini]

On Mon, Dec 09, 2024 at 08:00:33AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 8 Dec 2024 at 12:07, Tom Rini <trini at konsulko.com> wrote:
> >
> > Hey all,
> >
> > First, thanks to Simon Glass and also Linaro, we now have access to a
> > few fast arm64 host machines in our Gitlab instance, to use as CI
> > runners. This series finishes the work that I pushed earlier and Simon
> > had started that enables arm64 hosts to be used for most things now.
> >
> > The first notable change, especially if you use this on your own Gitlab
> > instance is that "DEFAULT_TAG" is now unused and we instead have:
> > - DEFAULT_ALL_TAG:
> > - DEFAULT_ARM64_TAG:
> > - DEFAULT_AMD64_TAG:
> > - DEFAULT_FAST_AMD64_TAG:
> >
> > This lets us say that some jobs can be run on all runners, because they
> > are small enough that anything we'd connect to CI is fast enough and it
> > also does not depend on the underlying host architecture. Next we have
> > tags for any arm64 host, or any amd64 host. Finally, we have a tag for
> > fast amd64 hosts. What these last three are for is that we have a few
> > jobs that need to run on amd64 hosts and so we have to restrict them
> > there, but we also have now reworked the world build jobs to build
> > (almost) everything in a single job and on the fast amd64 machines this
> > is still as quick as the old way was, in practice.
> >
> > To reach this point, we say that the Xtensa jobs can only run on amd64
> > hosts. Our targets only work with the binary-only toolchain and so this
> > is a reasonable limit and we exclude them from the world build jobs. We
> > also need to deal with ensuring the right toolchain is used regardless
> > what the host architecture is and that we don't use the host toolchain
> > by accident. Finally, because some of these changes needed to be worked
> > out in the linter, fix some of the general warnings that notes as well.
> 
> I haven't tried out this series. Does this handle running multiple
> test.py runs at once? For me that ends up providing a large
> improvement in CI times (down to about 35 mins with just two fast
> runners).

That's a per-runner configuration option and so orthogonal to this
series. Given the breakdown between "all" jobs and "fast" jobs, throwing
a bunch of the small and short "all" jobs on a runner also doing a
world build should just be a few minutes slow down all around and
overall noise.

-- 
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/20241209/924cc50d/attachment.sig>