This is a draft until I can verify switching to Arm runners speeds things up; baseline is 8m21s.

Thanks @brettcannon for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

Sorry, @brettcannon, I could not cleanly backport this to 3.14 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker ac1ffd77858b62d169a08040c08aa5de26e145ac 3.14

Sorry, @brettcannon, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker ac1ffd77858b62d169a08040c08aa5de26e145ac 3.13

Probably its not a big deal, but after this pr WASI job started failing in CPython forks. An example: https://github.com/skirpichev/cpython/actions/runs/19054675947/job/54423101721?pr=1

Probably its not a big deal, but after this pr WASI job started failing in CPython forks. An example: https://github.com/skirpichev/cpython/actions/runs/19054675947/job/54423101721?pr=1

I did a build restoring the version of WASITIME to 38.0.2 and it succeeded. https://github.com/diegorusso/cpython/actions/runs/19098164627/job/54563276302

Then I ran again with WASITIME to 38.0.3 and it still works:
https://github.com/diegorusso/cpython/actions/runs/19098528844/job/54564549223

I'm not sure why it fails in your case.

It's the cache.

The Linux-wasi-sdk-25 cache on your fork is from the 29th (https://github.com/skirpichev/cpython/actions/caches?page=2&query=Linux-wasi-sdk-25), and this PR moved it to ARM on the 30th. Try deleting it and running again.

We could include the architecture in the cache key, but I doubt it's going to change again often, if at all. (Although this is the second time this has come up.)

It's the cache.

Thanks, I confirm.

but I doubt it's going to change again often, if at all. (Although this is the second time this has come up.)

I don't think too much people enable CI in forks. So, we don't risk by invalidating too much caches.