cargo-install Action

This GitHub Action provides faster version of the cargo install command.

⚠ ️NOTE: This is an experimental Action. ⚠

Table of Contents

• Why?
• How does this work?
• Example workflow
• Inputs
• Tool cache
  • Security considerations
• GitHub cache
• License
• Contribute and support

Why?

If you are using binary crates (such as cargo-audit, grcov, cargo-geiger and so on) in your CI workflows, you might have noticed that compiling these crates each time is irritatingly slow.

This Action speeds up the crates installation with some tricks, leading to a much faster job execution; crates are expected to be installed in a couple seconds.

How does it work?

Before calling your usual cargo install command, this Action attempts to download pre-build binary crate file from the binary crates cache. See Security considerations to read more about potential caveats and usage policy.

If requested crate does not exist in the crates cache storage, this Action will fall back to the usual cargo install.\ As soon as actions-rs/meta#21 will be implemented, this Action will also cache compiled binary in the GitHub cache.

Example workflow

on: [push]

name: build

jobs:
  check:
    name: Rust project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/install@v0.1
        with:
          crate: cargo-audit
          version: latest
      - run: cargo audit

Inputs

Tool cache

As it was mentioned in How does it work? section, this Action can use external pre-compiled crates cache.

In order to enable this functionaliy, you need to explicitly enable use-tool-cache input:

- uses: actions-rs/install@v0.1
  with:
    crate: cargo-audit
    version: latest
    use-tool-cache: true

Before enabling this input, you should acknowledge security risks of executing binaries compiled for you by a third party in your CI workflows.

Security considerations

Check the tool-cache repo to understand how binary crates are built, signed and uploaded into the external cache.

This Action downloads both binary file and its signature. Signature validation is proceeded by openssl by using public key of the same certificate used for signing files at tool-cache repo.\ Public key is stored in this repository at public.pem.

If signature validation fails, binary file is removed immediately, warning issued and fall back to the cargo install call happens.

License

This Action is distributed under the terms of the MIT license, see LICENSE for details.

Contribute and support

Any contributions are welcomed!

If you want to report a bug or have a feature request, check the Contributing guide.

You can also support author by funding the ongoing project work, see Sponsoring.