Cargo builds on macOS runners have ephemeral failures

I have a question about running Cargo builds on macOS, and I was wondering if someone might know the answer.

We’ve been experience flaky builds (https://github.com/unicode-org/icu4x/issues/201) caused by ephemeral build errors that appear to have started showing up all of a sudden on a few PRs.

The error message in the log mentions error[E0463]: can't find crate for serde_derive which serde depends on, and when I looked through https://github.com/serde-rs/serde/issues/856 and similar issues (and verified the transitive dependencies’ versions of serde used, using cargo-tree), I don’t see the same serde version conflict problems that were described. And either way, I don’t think that would explain the ephemeral nature.

One possible theory is that it might relate to this issue from 3 years ago of cargo build failing on macOS due to linking issues when dependencies are added (https://github.com/rust-lang/cargo/issues/4775). I don’t know if that is still relevant to cargo builds. The GH builds that use the GH caching action (thereby retrieving cargo crate cache) are the ones that seem to fail ephemerally (ex1, ex2). The tests run after I turned off the GH caching action seem to pass (ex1, ex2). And FWIW, in my personal fork, even when I leave the GH cache action on, the builds pass (ex1, ex2).

Any pointers or suggestions would be appreciated, thanks.

[lilith]

It sounds like this is related to needing GNU tar instead of BSD tar on OS X- https://github.com/actions/cache/issues/403

[lilith]

I think we’re encountering this too with https://github.com/imazen/imageflow

We have a large build and caching is really important. Has anyone figured out how to fix it?