https://pantsbuild.org/ logo
Join Slack
Powered by
okay, muddling through the release process for the...
# development
c
okay, muddling through the release process for the first time. Hope I did the right branches. ;-) Don't just rubber stamp! https://github.com/pantsbuild/pants/pull/21492 https://github.com/pantsbuild/pants/pull/21493 https://github.com/pantsbuild/pants/pull/21496 In particular, I'm baffled by this 2.23.x failure https://github.com/pantsbuild/pants/actions/runs/11186939702/job/31108555617
f
Maybe there is a corruption in Cargo's cache of the Rust sources for the referenced crate?
Or something else funky in those sources?
g
Try deleting the cache for that failure and rerunning, I had a similar issue last week.
c
Hit the delete button on a lot of caches to no avial. This dummy PR against the branch also fails: https://github.com/pantsbuild/pants/pull/21502
g
Have you removed 
Linux-x86_64-rustup-f6dd272f455d1d27eb3ff80248865f66f71f0c1c5d84df1bff8cb06e7262bab0-v2
? That's the one with the toolchain, and it was a hit there.
(I'm very confused why this'd fail... the rustversion checks are defined as the inverse of one another iirc. Hence why I'm wondering thinking about the toolchain.)
c
Deleted every cache with 
21502
anyone on the table, same result on the dummy PR. 😕
(Also unable to reproduce locally with x86_64 Linux)
f
Would it make sense to just bump the 
strum
and 
strum_macros
crates to v0.26.x? (from their current v0.24.x) https://crates.io/crates/strum
that would force cargo to download the new versions
(and "break" the cache in a different way)
c
I don't think there is any reason not update those crates. At least it sounds like a helpful debugging step
f
also this error seems like the cause:
Copy code
error[E0463]: can't find crate for rustversion
With the 
rustversion
crate missing, the attribute from that crate used on on two different versions of the 
filter_by_rust_version
function in 
strum_macros
ends up not working and including both variants, when one of them should have been compiled out.
Bumping 
rustversion
to its latest version might also work.
and only involves a patchlevel bump
(that version is from v0.26 though but the code seems the same)
https://github.com/pantsbuild/pants/pull/21503 has the 
rustversion
bump. How far should it be back-ported?
just Pants v2.23?
c
just Pants v2.23
That is the only branch I've seen the strange behavior one
f
Feel free to approve and merge whenever convenient.
c
Slightly new and still confusing error on https://github.com/pantsbuild/pants/pull/21505
f
Now it can’t find the 
peg
crate: error[E0463]: can't find crate for 
peg
I suggest setting 
CARGO_LOG
to 
debug
for that build. https://doc.rust-lang.org/cargo/reference/environment-variables.html
Thought: When Cargo switched to sparse crate index, do we still cache the whole index?
And I also note that the Rust cache GitHub Action was forked by @happy-kitchen-89482. Maybe there is a bug fix in a more recent upstream version?
g
I looked at that when I was on rotation because I also had spurious CI failures. Nothing stood out to me, though upstream didn't have a great changelog.
c
Just for debugging completeness here, reverting the last commit on the 2.23.x branch also fails: https://github.com/pantsbuild/pants/pull/21508
g
It looks to be something in the cargo cache though; nuking v0-rust-engine-e0532086d687e04a7f4f4e4d77d7b4b4ebfae6f8-bb3b98c13a0bc788af42ec74262903f909eb39f1 does resolve it.
f
Are there caches for cargo coming from somewhere else?
g
f
I still think we should run with 
CARGO_LOG=debug
that is the recommended way from cargo project to debug stuff like this
(seems that way from having read through some of their project's issues)
g
There's quite a few bugfixes around how cache restore and save works upstream. Did a mostly line-by-line diff... Particularly, a particular cache mismatch will now cause mostly a a full clean of the target dir, if I'm reading the code correctly, while the fork will only remove unreferenced packages. The original fork seems to be to avoid wiping ~/.cargo/bin on persistent runners, not sure if that's still an issue.
f
Why did we fork?
Curious what patches we are carrying
g
The original fork seems to be to avoid wiping ~/.cargo/bin on persistent runners, not sure if that's still an issue
f
Maybe we could try the upstream cache action and see how it goes?
g
Yeah, maybe. I think it'd lead to the same issues that lead to the original fork, but I'm not sure if we use persistent runners or a dynamic pool. I recall it being changed? But it's a bit interesting I think that this issue only seems to affect Linux..? Mac does a cache restore but also rebuilds rustversion from scratch. Same cache source (commit/lockfile), so would expect similar outcomes.
h
I can merge the latest upstream into the fork and try that out
The wiping of ~/.cargo/bin is still an issue I believe
c
It looks to be something in the cargo cache though;
I am confused because I tried that? Maybe I missed some trash can buttons. All 3 release PRs should be good to go now.
g
Yeah; I'm a bit confused, but the things I looked at now point at: • On the failed original build for Linux, there was multiple cache restores - one of them being cargo which includes target dir ◦ This did not compile 
rustversion
but also did not find it when building 
strum_macros
◦ On this specific run, all the other Rust test steps did succeed, also restoring from cache but do build rustversion I then deleted the cargo cache, which again includes target dir, and reran: • There was no cache restore ◦ 
rustversion
was built as part of the build ◦ The build succeeded
c
Thank for your help! (To the original start of this thread, I think these release Pars are ready)
✅ 1
❌ 1
3️⃣ 1
15 Views
Open in Slack
PreviousNext
Powered by