crates installed for CI dependencies aren't cached

[stevenh]

If the workflow includes the install of additional cargo crates for example the install of cargo-udeps to validate that unused dependencies don't exist in Cargo.toml the depencent crates for the install don't appear to be cached, resulting in extended workflow build times.

In our case we're seeing over 11mins added to some builds due to this missing items.

It seems like these tool dependencies are been explicitly cleaned out before the cache is persisted?

Another related issue seems to be the key might not be taking into account items in the bin directory. If this is the case when the workflow changes to install additional tools the cache doesn't include them forcing rebuilds until the old cache expires.

[stevenh]

Would be simple to add an option to override the default behaviour, if this is a correct analysis?

If so I can put together a PR.

[stevenh]

Reading through the code that generates the lock key it does seem that the contents of the bin directory isn't considered just rust-toolchain, rusttoolchain.toml, Cargo.toml and Cargo.lock which seems to confirm that external tools aren't considered.

One workaround could be to customise key with the hash of the relevant binaries, but that would need everyone to do so.

What about adding the output from cargo install --list to the hash?

[Boshen]

@stevenh For cargo-udeps, I wonder if this helps with your build times (it's working for me)

  check-dependencies:
    name: Check Unused Dependencies
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - uses: dorny/paths-filter@v2
        id: filter
        with:
          filters: |
            src:
              - 'Cargo.lock'

      - name: Install cargo-udeps
        if: steps.filter.outputs.src == 'true'
        uses: taiki-e/install-action@cargo-udeps

      - if: steps.filter.outputs.src == 'true'
        run: cargo udeps

[stevenh]

Ooo thanks for sharing that @Boshen nice!