@GuillaumeGomez wrote

It is run it 3 CIs: gnu-tools, llvm-16 and llvm-17.

What is the value of running it in more than one job? The LLVM version doesn't affect the GCC backend, does it?

But also, this really should be cached somehow.

@Mark-Simulacrum mentionned that the caching should be done automatically since the Docker builds are cached.

Docker builds aren't actually cached on PR CI, just on auto/try builds.

Did that regress recently? I feel like the S3 based caching did work on PR CI - I don't quite understand why we can't fetch (without ever putting) the cache from PR builds.

Hmm, I thought that this has never worked, because there was nothing to fetch, since nothing was uploaded. But now I realize that this was probably only the case for mingw-check and in general for PR workflows that were not also executed on auto/try builds. For the other workflows, it probably was possible to cache the images, since they were shared on PR and auto/try builds.

In that case the regression most likely came from the Docker caching change, where we stopped using S3 and switched to a Docker registry instead. I'll take a look if we can use caching on PR workflows where the Docker image is shared.

Should be greatly improved once #122496 is merged.

Yeah that speeds it up to around 7.5 minutes.

This question remains open, though:

What is the value of running it [the GCC backend] in more than one job? The LLVM version doesn't affect the GCC backend, does it?

It doesn't. It's mostly about config I think.

I don't know what you mean by that. We should only be running GCC tests (and building GCC) in one job, unless doing it in multiple jobs gives us more coverage. (Probably one PR job and one bors job, as AFAIK those are defined independently. But maybe they share base images or so, I don't know how that is set up.)

I mean that we test backends if certain config are turned on. We just need to change them. I don't think running it in multiple CI is bringing any advantages. However I'm worried that just like when we changed the LLVM version, the tests for the GCC backend were dropped. iirc, it's when we decided to run GCC backend tests in all LLVM CIs.

I'm not advising against doing it or anything. Just that even if low, chances are not null. We need to find a solution for this regression to not happen again. It would indeed be interesting to see how cranelift is tested.

Btw: #122563 should fix the caching problem, after it PR CI should be hopefully fast (again).