Skip to content

Scan content of $CARGO_HOME/bin on restore instead of relying on cargo install metadata #325

Open
clechasseur wants to merge 1 commit intoSwatinem:masterfrom
clechasseur:feat/cargo-binstall-support
Open

Scan content of $CARGO_HOME/bin on restore instead of relying on cargo install metadata #325
clechasseur wants to merge 1 commit intoSwatinem:masterfrom
clechasseur:feat/cargo-binstall-support

Conversation

@clechasseur
Copy link
Copy Markdown

The current implementation of getCargoBins to check which binary is installed in $CARGO_HOME/bin checks the content of $CARGO-HOME/.crates2.json to determine which binary is preinstalled. When saving cache, all binaries not found in that file are removed to avoid caching them.

This means, however, that anything installed via a mean other than cargo install (like for example via cargo-binstall) won't be cached.

This PR changes the logic: now, when restoring cache, the $CARGO_HOME/bin directory is scanned and all files there are kept in the action state. When saving the cache post-install, all binaries that were in the directory at the beginning are removed; all others are cached. This allows the use of something like cargo-binstall or taiki-e/install-action, while still benefiting from caching.

I've also added a new workflow to test with cargo-binstall.

Let me know if there's something I should update as well.

Instead of relying on `.crates2.json` to know which binaries are installed,
scan the bin directory and save the result in the action's state.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant