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
We used - uses: Swatinem/rust-cache@v2 (default config).
We got on github ubuntu runners and on github ubuntu larger runners:
error: failed to run custom build command for `rustls v0.23.13`
Caused by:
could not execute process `/home/runner/work/project/project/target/debug/build/rustls-0580a0c717b029e3/build-script-build` (never executed)
Caused by:
No such file or directory (os error 2)
warning: build failed, waiting for other jobs to finish..
But when happend? When I updated Cargo.toml to new prost/tonic.
Crates on which failed was rustls, ring, and some other crates like. rusttls failed, but it was using just rustversion, which just checked RUSTC or RUSTC_WRAPPER env vars.
After tinkering, just disabled cache and all become good.
Fix: make default cache keys more specific and report to CI user cache churn explicitly
Why?
We think is that where is cache churn, we build mac darwin m1 some C++ clib or linux x86(gnu or musl) targets - 10GB not enough, seems builds kick cache back and forth, and if caches are shared, sometimes wrong files get into under key reused by other build in incompatible way.
So we need to know when there is churn(can action report it?)?
And also can we add some specific key part(and make it default), to ensure no conflicts?
The text was updated successfully, but these errors were encountered:
We used
- uses: Swatinem/rust-cache@v2
(default config).We got on github ubuntu runners and on github ubuntu larger runners:
I used
-vv
, andNothing was clarified. Was thinking strace.
But when happend? When I updated Cargo.toml to new prost/tonic.
Crates on which failed was rustls, ring, and some other crates like. rusttls failed, but it was using just rustversion, which just checked RUSTC or RUSTC_WRAPPER env vars.
After tinkering, just disabled cache and all become good.
Fix: make default cache keys more specific and report to CI user cache churn explicitly
Why?
We think is that where is cache churn, we build mac darwin m1 some C++ clib or linux x86(gnu or musl) targets - 10GB not enough, seems builds kick cache back and forth, and if caches are shared, sometimes wrong files get into under key reused by other build in incompatible way.
So we need to know when there is churn(can action report it?)?
And also can we add some specific key part(and make it default), to ensure no conflicts?
The text was updated successfully, but these errors were encountered: