actions-rs/install

⏩ GitHub Action for a faster binary crates installation

install's Issues

HTTP 403 from the tool cache

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

When actions-rs/[email protected] tries to download a crate from the tools cache, it gets an Unexpected HTTP response: 403.

Workflow code

name: Deploy

on: push

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Install Rust tools
        uses: actions-rs/toolchain@v1
        with:
          profile: minimal
          target: wasm32-unknown-unknown
          toolchain: stable
          override: true

      - name: Install Trunk
        uses: actions-rs/[email protected]
        with:
          crate: trunk
          version: latest
          use-tool-cache: true

Action output

Run actions-rs/[email protected]
  with:
    crate: trunk
    version: latest
    use-tool-cache: true
    use-cache: true
Tool cache is explicitly enabled via the Action input
Downloading from the tool cache
  Newest trunk version available at crates.io: 0.8.2
  Downloading trunk signature into /tmp/trunk.zip.sig
  Warning: Unable to download trunk == latest from the tool cache: Error: Unexpected HTTP response: 403

Expected behavior

That Trunk got quickly installed using the tool cache.

Install using specific rustc version

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
  Possibly! It depends how much free time I have.

Motivation

I'd like to be able to install tools like cargo-web and cargo-hack and be able to use them even on older compilers. To do this, the tools need to be installed using a more recent rustc (typically stable is more than sufficient), as the tools have a different MSRV than the code I'm testing.

Workflow example

on: [push]

name: build

jobs:
  check:
    name: Rust project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/[email protected]
        with:
          crate: cargo-audit
          version: latest
          rustc: stable
      - run: cargo audit

This would be equivalent to performing cargo +stable install cargo-audit.

I don't know if/how this would interact with the toolchain cache.

Action fails if binary already exists

Description

Github action fails if binary already exists.

Workflow code

    - name: Rust install cargo-deb
      uses: actions-rs/[email protected]
      with:
        crate: cargo-deb
        version: latest

Action output

  Newest cargo-deb version available at crates.io: 1.24.0
  Downloading cargo-deb signature into /tmp/cargo-deb.zip.sig
  Downloading cargo-deb == 1.24.0 into /tmp/cargo-deb.zip
  Starting signature verification process
  /usr/bin/openssl dgst -sha256 -verify /home/runner/work/_actions/actions-rs/install/v0.1/public.pem -signature /tmp/cargo-deb.zip.sig /tmp/cargo-deb.zip
  Verified OK
  Extracting files into /home/runner/.cargo/bin
  /usr/bin/unzip /tmp/cargo-deb.zip
  Archive:  /tmp/cargo-deb.zip
  replace cargo-deb? [y]es, [n]o, [A]ll, [N]one, [r]ename: 
  ##[error]The operation was canceled.

Expected behavior

Need an option to ignore/replace binary if it exits.

Additional context

Cache compiled binaries in the GitHub cache storage

With actions-rs/meta#21 resolved, this Action can remove the "tool-cache" functionality and instead just cache compiled binary.

Allow specifying features for the installed crates

Motivation

I currently use this line in my workflows:

cargo install --features postgres --no-default-features diesel_cli

This action currently doesn't allow specifying features (or removing default features) of a crate, and that would be nice.

Workflow example

on: [push]

name: build

jobs:
  check:
    name: Rust project
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/[email protected]
        with:
          crate: diesel_cli
          version: latest
          features: postgres
          default-features: false
      - run: diesel migration run

Additional context

If we want to also support cache for this, we would need to add cache for different feature matrices, which might prove difficult.

Unable to access certificate file at runtime

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

When attempting to verify the downloaded binary, the action's code is unable to find the public key file (public.pem).

Workflow code

- uses: actions-rs/[email protected]
    with:
      crate: cargo-web
      version: latest
      use-tool-cache: true

Action output

Run actions-rs/[email protected]
Installing "cargo-web = latest"
Run actions-rs/[email protected]
  with:
    crate: cargo-web
    version: latest
    use-tool-cache: true
    use-cache: true
Tool cache is explicitly enabled via the Action input
Downloading from the tool cache
  Newest cargo-web version available at crates.io: 0.6.26
  Downloading cargo-web signature into /home/runner/.cargo/bin/cargo-web.sig
  Downloading cargo-web == 0.6.26 into /home/runner/.cargo/bin/cargo-web
  Starting signature verification process
  /usr/bin/openssl dgst -sha256 -verify public.pem -signature /home/runner/.cargo/bin/cargo-web.sig /home/runner/.cargo/bin/cargo-web
  Can't open public.pem for reading, No such file or directory
  140636534547520:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('public.pem','r')
  140636534547520:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
  unable to load key file
  ##[warning]Unable to validate signature for downloaded cargo-web!
  ##[warning]Unable to download cargo-web == latest from the tool cache: Error: The process '/usr/bin/openssl' failed with exit code 1
Falling back to the `cargo install` command

Expected behavior

I expected the binary to be verified successfully and bypass rebuilding it on each CI run.

Additional context

I'd like to help with this issue, but am a little out of my depth since I'm new to Actions. I see the key file committed in the repository here, but i'm not sure how it would get copied over into the right spot at runtime. Thanks!

Strange freeze when installing sccache

Description

The bug I am seeing is that once I push commits to a PR, the install action freezes for indefinite amount of time (IIRC it will bail after 5+ hours of freeze but I cant find this run anymore...)

Here is a recent run, sorry the project is private, I can't give a link to the workflow.
After 25 minutes of idling I canceled the workflow and here are the logs:

Workflow code

    - name: Cache sccache cache
      uses: actions/cache@v1
      with:
        path: ${{ env.SCCACHE_DIR }}
        key: sccache-cache-${{ hashFiles('**/Cargo.toml') }}
    - name: Install sccache
        uses: actions-rs/[email protected] 
        with:
          crate: sccache
          use-tool-cache: true
          version: latest

Textual logs

Run actions-rs/[email protected]
Tool cache is explicitly enabled via the Action input
Downloading from the tool cache
  Newest sccache version available at crates.io: 0.2.13
  Downloading sccache signature into /tmp/sccache.zip.sig
  Downloading sccache == 0.2.13 into /tmp/sccache.zip
  Starting signature verification process
  /usr/bin/openssl dgst -sha256 -verify /home/runner/work/_actions/actions-rs/install/v0.1/public.pem -signature /tmp/sccache.zip.sig /tmp/sccache.zip
  Verified OK
  Extracting files into /home/runner/.cargo/bin
  /usr/bin/unzip /tmp/sccache.zip
  Archive:  /tmp/sccache.zip
  replace sccache? [y]es, [n]o, [A]ll, [N]one, [r]ename: 
  ##[error]The operation was canceled.

What is interesting is that after canceling workflow and hitting the rerun button everything works fine.
I suppose the problem is that there is a call to unzip utility that is run in interactive mode...

Support installing crates using Git URLs

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

As an action-rs/install user, it would be useful to have the ability to also install crates using Git URLs, and not just crates published on crates.io.

Also it would match the actual cargo install command better, since it has the --git/--branch/--tag/--rev flags precisely for this purpose.

One use-case for example is old, unmaintained crates with a new fork that doesn't have its own published crate.

Workflow example

- uses: actions-rs/[email protected]
  with:
    crate: cargo-audit
    version: latest
    git: https://github.com/RustSec/cargo-audit
    use-tool-cache: true

- uses: actions-rs/[email protected]
  with:
    crate: cargo-audit
    version: latest
    git:
      repo: https://github.com/RustSec/cargo-audit
      branch: master
      tag: v0.12.1
      # rev: d3017c3
    use-tool-cache: true

Support `--locked` on cargo install

Support passing --locked to cargo install.

Motivation

Some binary crates are outdated and have suboptimal Cargo.toml files. In that case, it can occur that the dependencies listed in Cargo.toml were updated since the crate was published and an incompatibility arises. These crates can then only be succesfully installed by passing --locked which causes the Cargo.lock to be used if it is published by that binary crate.