https://pantsbuild.org/ logo
Join Slack
Powered by
Does `error: not a file: '/home/runner/.rustup/too...
# development
h
Does 
error: not a file: '/home/runner/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustfmt'
ring any bells: https://github.com/pantsbuild/pants/actions/runs/17995816692/job/51248424866
This is in src/python/pants/backend/rust/lint/rustfmt/rules_integration_test.py and doesn’t reproduce locally (and in any case seems completely unrelated to the change, which is just documentation, I’m not even sure why tests were triggered in the first place, maybe because I touched a README outside the docs/ dir)
Rerunning the job reproduces the error
Oh whoops just saw another post to this effect
c
the rust backend relies on the "stable" toolchain+rustfmt existing. (which we don't seem to install in CI?) I do not know how this worked before. https://github.com/pantsbuild/pants/pull/22703 is me banging my head against this without success so far
w
I started wondering if it was from the rusttls update or something. There was another spurious docker error in another action, but apparently DOcker Hub went down at some point. I've found some loose information on this while searching last night, and one of the things was that - if a rustup installation ever fails in CI - you don't really get notified or fixed. You just have to know to go in, wipe caches, and start again. Myabe that's an idea?
@curved-manchester-66006 rustfmt is "supposed" to be installed on the default ubuntu image: https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md
We're still using 1.89 though right? Is stable 1.90?
c
https://releases.rs/ has 1.90 as stable
w
Been stable for a week, so unless we're running into cache shenanigans (which, if you look at actions that passed/failed, could make sense)
The error is happening in our rust subsystem, backend/rust/subsystems/rust.py Does this mean having 
stable
on a machine is a bad default?
h
The cache errors you saw are suspicious, no?
w
The warnings are meh, but I noticed that some of the caches (maybe engine caches?, it was late at night) were different in passing/failing runs. It could be that pants cache expecting something, and what ubuntu has there right now are different? Though, how this folder doesn't exist 
/home/runner/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustfmt
blows my mind
But fundamentally it's a failing test that we could skip in the short term?
c
re the cache error: https://github.com/actions/cache says the min version is v3.4.0 but https://github.com/benjyw/rust-cache/blob/master/package.json#L25 pisn to v3.0.4
h
This is a test on a backend that isn’t really used, right?
f
Were there any recent changes in rustup?
also relevant context from we last dealt with rustup changes: https://github.com/pantsbuild/pants/pull/22037
w
Last rustup release was a few months ago. We had a rust dependabot change which would trigger an engine re-cache, and that worked, then started failing
f
also, when our Rust build scripts install Rust, they do so via the version name not 
stable
c
This is a test on a backend that isn’t really used, right?
yes the rust backend that only runs 
rustfmt
f
and I believe rustup treats those as two different toolchains
w
To @happy-kitchen-89482 point, yeah, we don't use that backend much - also, the test isn't really testing what we think it's testing - if the failure is the lack of system binary 🤷
f
so 
stable-x86_64-apple-darwin
!= 
1.89.0-x86_64-apple-darwin
w
To be fixed, but also skippable. Personally, I wouldn't mind wiping the whole pants actions cache (as well)
There are also some weird, weird things happening with CI timing. 45m or 1h10+ for stuff that shouldn't be affected, re-bootstrapping, and re-testing the engine I guess. on macos x86
c
(I might be close to a fix)
okay, options: • (A) Install 
stable
on test jobs. (I have this I think working, although now that I'm in the details I'm unsure how the prior state ever worked to begin with). • (B) Skip the test • (C) Make the test use the same version of rust has pants itself uses (This sounds reasonable but I could not get it to work)
w
(B) Skip the test, solve it as an aside - the fact that none of us really know why it worked, and why it fails is a bit concerning. And installing stable might balloon our cache even more
c
(A) https://github.com/pantsbuild/pants/pull/22704 (B) https://github.com/pantsbuild/pants/pull/22705 @happy-kitchen-89482 I'm assuming you are the right one to look at updating 
benjyw/rust-cache
(or tell me my hunch is wrong)
h
So we can target 
v2.8.1
for example
w
Will this possible regression affect anything? https://github.com/Swatinem/rust-cache/issues/264
c
just use upstream
🥳
(landed option (B) and 
main
is open for business again)
🔥 1
4 Views
Open in Slack
PreviousNext
Powered by