Hi Tom, On Sun, 8 Dec 2024 at 12:07, Tom Rini <[email protected]> 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). Regards, Simon
