In a virtual workspace the root `Cargo.toml` is not a package, so the cache key hashed only the
members' manifests and left out the root's `[profile]`, `[patch]` and `[workspace.dependencies]`
(#268). Editing one of those, such as a `[profile.dev]` opt-level, kept the same key: every run
restored the stale cache as an exact hit, rebuilt what the edit invalidated, and saved nothing, so
the rebuild repeated on every run until something else changed the key.
This change hashes the root manifest of the workspace `cargo metadata` reports, along with its
members' manifests. It ignores `workspace.package.version` and the paths and versions of path
dependencies in `[workspace.dependencies]`, as it already does for members, so a release version
bump still keeps the key. It also reads `Cargo.lock` from that root, so a `workspaces` entry that
points at a member directory now hashes the lockfile that builds it. A workspace whose root is a
package keeps its key, and a virtual workspace gets a new one once.
The timestamp branch in rmExcept returned after the first directory
entry, so at most one outdated item was ever removed. Replace the early
return with continue so every entry is checked.
Some self-hosted (or otherwise non-github-hosted) runners are
non-case-preserving for cache keys. To support such configurations, set the
`cache-hit` output variable to `true` if the found cache key matches
case-insenitively.
Fixes: https://github.com/Swatinem/rust-cache/issues/302
The values for the dependencies could be strings intead of objects, so
add a `try` block to take care of that.
Also set `dep.path` to `""` if the dependency contains a key `path` to
make sure that the cache isn't invalidated due to change in workspace.
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
This simple mistake caused the entire `Cargo.lock` to be ignored (JS
treats having no return as `false`).
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
There are a few problems in cargo-binstall where sometimes change to
`Cargo.lock` does not invalidate the cache.
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>