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@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.