You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update (2025-02-13): GitHub has changed the new large runners to Neoverse N1 CPUs. The underlying issue is not fixed, but GHA large aarch64 runners should now work fine with Ubuntu 24.
This was the cause of the problems we had using ubuntu-24.04-arm in test-fast (#1790), and probably the cause of the problems we had using it in test-32bit (including #1780). It is likely feasible to go back to using ubuntu-24.04-arm now, reverting #1802 and #1830, respectively.
This is a tracking issue for that. I hope to open a PR soon. This is an issue rather than starting out as a PR because fairly heavy testing is needed to determine if the problems still sometimes occur, and I don't want to run hundreds of jobs on GitoxideLabs that I can run on my personal account. (This relates to rate-limiting; in neither case would payment be involved. But it is also because I have more ability to cancel and rerun jobs that run in my fork.) There are multiple ways to achieve that, but not having a related PR at all while doing those tests is the simplest way to achieve it even if I make mistakes, and the code changes to the workflows are not themselves interesting.
Motivation 🔦
We had preferred to use ubuntu-24.04-arm initially, which matches the current ubuntu-latest version which is currently equivalent to ubuntu-24.04. I think ubuntu-24.04-arm is intended, or intended eventually, to run on faster machines than ubuntu-22.04-arm, though I could have misunderstood. Because it looks like ubuntu-24.04-arm should work here again, there is also a benefit to trying again for it, since if problems still occur, I can try to report them.
I think switching back to 24.04 for the ARM Linux jobs is not a priority, but it also probably does not require a high amount of time or effort to attempt. Therefore, so long as I manage to test enough runs to have a reasonably good degree of belief that the problems we had are fixed, I think this is worth doing now.
Edit: The testing worked out, and I've opened PR #1867.
The text was updated successfully, but these errors were encountered:
Summary 💡
A couple of weeks ago, rust-lang/rust#135867 has been updated to note:
See also rust-lang/rust#135867 (comment) and actions/partner-runner-images#36 (comment).
This was the cause of the problems we had using
ubuntu-24.04-arm
intest-fast
(#1790), and probably the cause of the problems we had using it intest-32bit
(including #1780). It is likely feasible to go back to using ubuntu-24.04-arm now, reverting #1802 and #1830, respectively.This is a tracking issue for that. I hope to open a PR soon. This is an issue rather than starting out as a PR because fairly heavy testing is needed to determine if the problems still sometimes occur, and I don't want to run hundreds of jobs on GitoxideLabs that I can run on my personal account. (This relates to rate-limiting; in neither case would payment be involved. But it is also because I have more ability to cancel and rerun jobs that run in my fork.) There are multiple ways to achieve that, but not having a related PR at all while doing those tests is the simplest way to achieve it even if I make mistakes, and the code changes to the workflows are not themselves interesting.
Motivation 🔦
We had preferred to use
ubuntu-24.04-arm
initially, which matches the currentubuntu-latest
version which is currently equivalent toubuntu-24.04
. I thinkubuntu-24.04-arm
is intended, or intended eventually, to run on faster machines thanubuntu-22.04-arm
, though I could have misunderstood. Because it looks likeubuntu-24.04-arm
should work here again, there is also a benefit to trying again for it, since if problems still occur, I can try to report them.I think switching back to 24.04 for the ARM Linux jobs is not a priority, but it also probably does not require a high amount of time or effort to attempt. Therefore, so long as I manage to test enough runs to have a reasonably good degree of belief that the problems we had are fixed, I think this is worth doing now.
Edit: The testing worked out, and I've opened PR #1867.
The text was updated successfully, but these errors were encountered: