test canonical s390x runner

[marcoieni]

Ignore this PR for now.

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