Sharing TARGET_DIR leads to spurious missing items

[l4l]

Problem

I'm using a shared target directory for a CI runner that allows to run builds (fmt, clippy, doc, build, etc) concurrently. Incremental builds are disabled.

Since the sharing target the builds are failing sporadically with usually with compile errors like this:

error[E0463]: can't find crate for eyre

And eyre hasn't been touched for a while. What I found so far is the following case. Two CI jobs was executing simultaneously on the same runner:

1. cargo nextest run --profile ci --all-targets --all-features <-- building just the first target
2. cargo test --doc --all-features <-- building doc test for some crate (after running same nextest cmd and built default test target)

The project is a workspace with lots of members. The compile error for the first job is no method named <func> found for .. in the current scope and the commit for the second jobs actually removes this function, which lead me to conclusion this setup does not work correctly. Apparently locks only held only per-target basis thus leading to race condition where dependency has been overwritten.

So far I'm not sure it's a bug really but at least there's #2486 which led me thinking the setup should work.

Version

cargo 1.77.2 (e52e36006 2024-03-26).

[epage]

There are two aspects here that are likely going wrong

• You are using a third-party test runner which likely doesn't participate in our locking (though it would be delegating to cargo for builds which would be locked)
• What all operations are performed under the target directory lock.

How much room for improvement there is, I'm unsure. That would take a bit more investigation.

[DXist]

There is a related issue about path dependencies in 2 workspaces with the same name and version.

In the case of concurrent CI jobs there are 2 distinct repository checkouts (in different directories or containers depending on CI executor).

When

• version of a path dependency doesn't change ("0.0.0" is a typical version for path dependencies in the same repository)
• but one of the directories contains backwards incompatible change of this dependency (like removed crate item)

one of the jobs uses build result of the another job.

It seems that cargo doesn't distinguish between two path dependency variants.