Caching tracking issue

[svartalf]

There are two things that can be improved with caching added:

1. Cache target/ and Cargo folders (see an example)
2. Cache the compiled binary from the cargo install {pkgid} command

Right now this affects the following workflows:

• actions-rs/cargo with use-cross: true input enabled (cross is compiled on each call)
• Download and run cargo-tarpaulin from GitHub releases tarpaulin#1
• cargo tomlfmt #20
• semverver #13
• cargo udeps #11
• Caching of Build Artifacts #5

This issue can be solved by a proper implementation of the actions-rs/core/Cargo.installCached function, see actions-rs/core#31, but it is blocked by actions/cache#55

Right now this issue acts only as a tracking issue for a possibility of proper caching implementation.

[CAD97]

In rust-analyzer, we remove artifacts for the workspace-local files before the cache stores. While this isn't required to reduce cache churn like it does on auto-keyed caching (e.g. Travis) (as a matching key will not store the cache), it does still reduce cache sizes.

If actions-rs ever provides a "best practice" caching wrapper, it should probably allow scrubbing these files, so only dependencies' artifacts are cached. (Specifically, scrubbing files directly in ./target/{debug,release}/ as well as folders/files directly in ./target/{debug,release/{.fingerprint,deps,incremental}/ that contain the names of workspace-local libs/bins.

[svartalf]

@CAD97 noted, thank you! I do want to create some kind of actions-rs/cache, which will cache all these things automatically, but as this issue points to, there is no programmatic access to the cache routines right now.

[anp]

Lucky timing, but looks like a few hours before I came across this issue someone posted a possible workaround to the upstream issue: actions/cache#55 (comment).

Also worth noting that in addition to the target/ directory examples, currently I have these cache keys set up in my jobs:

    - name: cache cargo index
      uses: actions/cache@v1
      with:
        path: ~/.cargo/git
        key: cargo-index-${{ hashFiles('**/Cargo.lock') }}
        restore-keys: |
          cargo-index-
    - name: cache cargo registry
      uses: actions/cache@v1
      with:
        path: ~/.cargo/registry
        key: cargo-registry-${{ hashFiles('**/Cargo.lock') }}
        restore-keys: |
          cargo-registry-

[thomaseizinger]

There is an initial version of @actions/cache available now: https://github.com/actions/toolkit/tree/master/packages/cache

[mzabaluev]

One problem with using a hash of Cargo.lock in the cache key is that for library crates, checking Cargo.lock into version control is discouraged. So there may not be enough data in the repository checkout so that the cache action could score the hit with the dependencies exactly right for the build, before cargo fetch or cargo update generates Cargo.lock locally. But these commands also fetch the dependencies, so they would benefit from some hopefully close snapshot of ~/.cargo/registry to be restored from the cache already.

I have developed a workflow solution that maintains a Cargo.lock checked in and automatically updated in a special git branch. In every workflow run that uses cargo to build, Cargo.lock is grafted on top of the commit that triggered the build, and then the hash of Cargo.lock is used as the last part of the cache key for restoring ~/.cargo/registry. The hope is that the lockfile generated off the latest master tree often suits the build of a somewhat divergent revision with no new dependency crates to fetch. This is probably too much complexity for a single GitHub action to hide, though.