A relatively significant amount of CI compute time is spent on Renovate updating taiki-e/install-action once per week. This action is the documented method of using cargo-hakari in CI.
install-action updates several times per week, but none of these updates significantly change what is occurring; install-action does not directly handle the installation of cargo-hakari, and instead installs cargo-binstall to do it. cargo-binstall directly pulls from the latest GitHub Release for cargo-hakari.
It seems sensible, to me, to replace it with a single line of Bash, with the additional advantage of locking to a given release. cargo-hakari updates as-needed, and we can update the workflow as-needed too. (But if we want to always pull the latest I can write a tool to search for the latest release.)
actions-rs/toolchain is redundant here as we have a rust-toolchain.toml, and actions-rs/cargo was archived a year ago.
A relatively significant amount of CI compute time is spent on Renovate updating taiki-e/install-action once per week. This action is the documented method of using cargo-hakari in CI.
install-action updates several times per week, but none of these updates significantly change what is occurring; install-action does not directly handle the installation of cargo-hakari, and instead installs cargo-binstall to do it. cargo-binstall directly pulls from the latest GitHub Release for cargo-hakari.
It seems sensible, to me, to replace it with a single line of Bash, with the additional advantage of locking to a given release. cargo-hakari updates as-needed, and we can update the workflow as-needed too. (But if we want to always pull the latest I can write a tool to search for the latest release.)
actions-rs/toolchain is redundant here as we have a rust-toolchain.toml, and actions-rs/cargo was archived a year ago.