ci: build and test with s390x-resolute runner

[marcoieni]

We'd like to this add new s390x runner to compiler-builtins.

This new runner is provided by Canonical. After some iteration alongside with Canonical folks, the large runner offers hardware spec similar to the existing s390x provided by IBM and delivers similar build times.

Moreover, it runs on ubuntu-26.04 rather than ubuntu-24.04, and it features a Github integration more friendly to t-infra, since the related Github App requires less permissions to run.

We don't need to remove the s390x IBM runners right now. We propose having both s390x runners running side by side for a while and circle back after a few PRs, sticking with the Canonical one afterwards if everything goes well.

[tgross35]

(rebased to pick up 5ef80b3 and see where it's getting stuck)

[tgross35]

Oh - this needs to be the actual rust target

View changes since the review

[marcoieni]

the new runner might be slow due to the cache miss, I want to try to push a new commit to check how it behaves with the cache hit.

[tgross35]

It's building nextest from source since there's no binary for this arch, which is taking extra long too (though seems like the ubuntu-24.04-s390x image is reasonably fast?). If trying again with cache doesn't speed things up much, it might be worth an if: to disable on this runner at

compiler-builtins/.github/workflows/main.yaml

Lines 152 to 154 in 5ef80b3

	- uses: taiki-e/install-action@7a79fe8c3a13344501c80d99cae481c1c9085912 # v2.81.10
	with:
	tool: nextest@0.9.131

.

(edit: install-action actually has fallback: none)

[marcoieni]

we might ask Canonical if they can install cargo next test on the runner for us so that it is always available. Although we might not be able to pin the version 🤔

[tgross35]

I'm fine without an exact version as long as it's relatively recent, the pinning is mostly for Zizmor rather than needing specific features

[marcoieni]

Actually if we want to control the version, we could cache it 👀

Btw, there wasn't a cache hit even in the second run because I think the cache is populated only from the main branch.

This Canonical runner seems slower than the IBM one because to run cargo install of cargo nextest, it takes almost four times more.
So I assume there's no reason to merge this PR, since the s390x architecture is already covered by the ibm runner, right?

See:

[tgross35]

Actually if we want to control the version, we could cache it 👀

Just building once then putting it on ci-mirrors? That does sound nice 🤔. The nextest maintainers have been pretty open to adding arches if they get the CI resources, maybe we should ask if they'd apply to the IBM program.

Btw, there wasn't a cache hit even in the second run because I think the cache is populated only from the main branch.

I would have expected this to work, but the inner workings of GHA cache are a complete mystery to me 🙂

This Canonical runner seems slower than the IBM one because to run cargo install of cargo nextest, it takes almost four times more. So I assume there's no reason to merge this PR, since the s390x architecture is already covered by the ibm runner, right?

Up to you for what you're trying to get. If you wanted a persistent job to keep testing then we can figure out what to do with nextest, but the existing s390x job covers things well so it's also fine to close.

[marcoieni]

Just building once then putting it on ci-mirrors? That does sound nice 🤔

I was thinking more of caching the artifacts in github actions cache. It's easier and requires less maintenance. Similar to how we cache cargo artifacts now.

The nextest maintainers have been pretty open to adding arches if they get the CI resources, maybe we should ask if they'd apply to the IBM program.

this is also an option!

[tgross35]

I thought rust-cache takes care of those since it should cache the bin dir (I think?), but it also looks like the other s390x job had to rebuild. Hmm

[marcoieni]

I think the issue is the order of the steps, since the rust-cache action runs after the install action.

[ubiratansoares]

Aside caching, I found an interesting data point from this workflow run : it seems the IBM Runners have a significantly bigger CPU compared with the Canonical resolute-medium ones : 8 cores (vs 4 cores), bigger CPU caches, etc. I got this information by expanding logs from this step in both jobs.

I'd not be surprised if the IBM runner has bigger numbers for other hardware parameters like RAM/Disk sizes, IO perf, etc. That could explain the difference between the two jobs executions, at least partially.

[tgross35]

Looks like time is comparable to the other s390 job now. Thanks!

View changes since this review

[tgross35]

Actually I guess that one was fast because the cache was available, for this cold build it's taking a very long time. I think I'd like to wait for #1253 which should get rid of the time spent building nextest (cc @Gelbpunkt)