No cache is ever found, and a warning is printed in the post-run (using container)

[tomaka]

Example run: https://github.com/paritytech/smoldot/pull/396/checks?check_run_id=1761418426

Running the action always results in "No cache found.", even for trivial changes where I'm certain that none of the dependencies have changed.

A warning is always printed in the "post-run" stage, which might be the reason:

Warning: The "path" argument must be of type string. Received type undefined

[Swatinem]

I can see two issues:

1. Please use the action after your rustup invocation, as the action will use the currently active rustc version as part of its cache key.
2. It looks like you invoke cargo in a subdirectory. In that case, please use the working-directory option appropriately. I think that should take care of the warning you see.

[tomaka]

Thanks for the quick answer!

It looks like you invoke cargo in a subdirectory. In that case, please use the working-directory option appropriately. I think that should take care of the warning you see.

There is only one workspace, at the root. While the Cargo.toml that I compile is in a subdirectory, there is only one single Cargo.lock at the root of the repo. Should I still do that?

Please use the action after your rustup invocation, as the action will use the currently active rustc version as part of its cache key.

I'll fix that. However, the problem also happens on another job which does it properly:

  test:
    name: Build and test
    runs-on: ubuntu-latest
    container:
      image: rust
    steps:
    - uses: actions/checkout@v2
    - uses: Swatinem/rust-cache@v1
    - name: Run tests, with all features
      run: cargo test --locked --workspace --all-features

Example action run

[Swatinem]

Ah okay, when the Cargo.lock is in the repo root then it should be fine. I see you use containers in your job. TBH, I haven’t looked into how these work, and haven’t used them myself so far, but it may have an impact. Not really sure though.

NOTE to self: Better log CWD.

[vedhavyas]

I'm having the same trouble with recent release as well. This is the warning in my post-run

Warning:  The "path" argument must be of type string. Received type undefined

Here is thee run: https://github.com/centrifuge/centrifuge-chain/pull/378/checks?check_run_id=2713322634#step:13:2

Here is the workflow: https://github.com/centrifuge/centrifuge-chain/blob/0.9.3/.github/workflows/build.yml

Any thoughts @Swatinem ?

[Swatinem]

So the job itself runs on the normal machine, but the build happens in a container, and your target, etc folders are being mounted into it via volumes, right?

Can you enable verbose logging to see more of whats going on? https://docs.github.com/en/actions/managing-workflow-runs/enabling-debug-logging (keep in mind to disable that afterwards again) Its a bit annoying not to have a stack trace for that warning, meh :-(

[vedhavyas]

So the job itself runs on the normal machine, but the build happens in a container, and your target, etc folders are being mounted into it via volumes, right?

We are not using any containers. everything runs on the machine itself.

[Swatinem]

The log you linked to runs the build in docker here:

https://github.com/centrifuge/centrifuge-chain/blob/4c641e5320b191c8febff3fb841e037624bb2907/ci/script.sh#L50

[vedhavyas]

sorry. I spoke too soon :(
But it used to save the cache earlier. I added target-dir and started seeing this.

[dylanaraps]

Here's some logs. Same issue (build is executed in docker, repository is mounted inside the container).

why am I using docker?

I need a musl environment to statically compile some software.

github action files

(build.yml executes docker which calls build.sh within the container)

https://github.com/dylanaraps/eww-static-test/tree/master/.github/workflows

pre

##[debug]Evaluating condition for step: 'Run Swatinem/rust-cache@v1'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Run Swatinem/rust-cache@v1
##[debug]Register post job cleanup for action: Swatinem/rust-cache@v1
##[debug]Loading inputs
##[debug]Loading env
Run Swatinem/rust-cache@v1
##[debug]followSymbolicLinks 'false'
##[debug]followSymbolicLinks 'false'
##[debug]implicitDescendants 'true'
##[debug]omitBrokenSymbolicLinks 'true'
##[debug]Search path '/home/runner/work/eww-static-test/eww-static-test'
::save-state name=RUST_CACHE_HASH::d9aeb59c89ba1eea5951
##[debug]Save intra-action state RUST_CACHE_HASH = d9aeb59c89ba1eea5951
::save-state name=RUST_CACHE_BINS::["bindgen","cargo-audit","cargo-outdated","cbindgen"]
##[debug]Save intra-action state RUST_CACHE_BINS = ["bindgen","cargo-audit","cargo-outdated","cbindgen"]
Restoring paths:
    /home/runner/.cargo/bin
    /home/runner/.cargo/.crates2.json
    /home/runner/.cargo/.crates.toml
    /home/runner/.cargo/git
    /home/runner/.cargo/registry/cache
    /home/runner/.cargo/registry/index
    ./target
In directory:
    /home/runner/work/eww-static-test/eww-static-test
Using keys:
    v0-rust-build-1.55.0-nightly-x86_64-unknown-linux-gnu-6a758ea7e484-d9aeb59c89ba1eea5951
    v0-rust-build-1.55.0-nightly-x86_64-unknown-linux-gnu-6a758ea7e484
##[debug]Resolved Keys:
##[debug]["v0-rust-build-1.55.0-nightly-x86_64-unknown-linux-gnu-6a758ea7e484-d9aeb59c89ba1eea5951","v0-rust-build-1.55.0-nightly-x86_64-unknown-linux-gnu-6a758ea7e484"]
##[debug]Checking zstd --version
##[debug]*** zstd command line interface 64-bits v1.5.0, by Yann Collet ***
##[debug]Resource Url: https://artifactcache.actions.githubusercontent.com/UJyBnMrQkGirScsY21kqFa6IfDc6ruB2JK3cSGVjnK0AmaxAiO/_apis/artifactcache/cache?keys=v0-rust-build-1.55.0-nightly-x86_64-unknown-linux-gnu-6a758ea7e484-d9aeb59c89ba1eea5951%2Cv0-rust-build-1.55.0-nightly-x86_64-unknown-linux-gnu-6a758ea7e484&version=8a9936d632ad0d67adaee02f5d9fd8c1dddbbd5af8d94331392b76f17401cf6d
No cache found.

::set-output name=cache-hit::false
##[debug]='false'
##[debug]Node Action run completed with exit code 0
##[debug]CARGO_INCREMENTAL='0'
##[debug]Finishing: Run Swatinem/rust-cache@v1```

post

##[debug]Evaluating condition for step: 'Post Run Swatinem/rust-cache@v1'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Post Run Swatinem/rust-cache@v1
##[debug]Loading inputs
##[debug]Loading env
Post job cleanup.
##[debug]followSymbolicLinks 'false'
##[debug]followSymbolicLinks 'false'
##[debug]implicitDescendants 'true'
##[debug]omitBrokenSymbolicLinks 'true'
##[debug]Search path '/home/runner/.cargo/registry/index'
Warning:  The "path" argument must be of type string. Received type undefined
##[debug]Node Action run completed with exit code 0
##[debug]Finishing: Post Run Swatinem/rust-cache@v1

[alokedesai]

I'm also having this issue where no cache is ever found (without a container) when using a cargo workspace. Unfortunately, it's a private repo so I can't link to it but even something as simple as the job linked below doesn't find a cache key.

test:
    name: Warp Tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout sources
        uses: actions/checkout@v2

      - name: Install Rust toolchain
        uses: actions-rs/toolchain@v1
        with:
          profile: minimal
          toolchain: stable
          override: true
      - uses: Swatinem/rust-cache@v1

      - name: Run cargo test
        uses: actions-rs/cargo@v1
        with:
          command: test

@Swatinem any suggestions on how to best debug this?

Also thank you for your work on Sentry 🙏🏽 I've interacted with you on sentry prs before and you were super responsive, much appreciated!

[Swatinem]

@alokedesai Thanks for the kind words!

Apart from enabling detailed CI/step debug output as mentioned above (https://docs.github.com/en/actions/managing-workflow-runs/enabling-debug-logging), I can’t give more hints.
Though those logs should give you a hint of whats happening. You should also be seeing the list of files that is being persisted/restored (which in your case seems to be 0 though).

I may do a dependency bump again sometime, I see there was some recent activity for https://github.com/actions/toolkit/tree/main/packages/cache, though unfortunately github pretty much treats their actions toolkit as abandonware :-(

[lfrancke]

I decided to comment here because it seems related, happy to open a new issue.

We also now get this warning.
See here: https://github.com/stackabletech/zookeeper-operator/runs/5067729756?check_suite_focus=true#step:9:15

I enabled debug logging and this is what I get:

##[debug]Evaluating condition for step: 'Post Set up rust-cache'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Post Set up rust-cache
##[debug]Loading inputs
##[debug]Loading env
Post job cleanup.
##[debug]followSymbolicLinks 'false'
##[debug]followSymbolicLinks 'false'
##[debug]implicitDescendants 'true'
##[debug]omitBrokenSymbolicLinks 'true'
##[debug]Search path '/usr/local/cargo/registry/index'
Warning:  The "path" argument must be of type string. Received type undefined
##[debug]Node Action run completed with exit code 0
##[debug]Finishing: Post Set up rust-cache

This is using the official rust image: https://github.com/EmbarkStudios/cargo-deny-action/blob/v1.2.10/Dockerfile
Which is installing rust into /usr/local/cargo so I had to change CARGO_HOME for this run:

  run_cargodeny:
    name: Run Cargo Deny
    runs-on: ubuntu-latest
    env:
      CARGO_HOME: /usr/local/cargo
    strategy:
      matrix:
        checks:
          - advisories
          - bans licenses sources

    # Prevent sudden announcement of a new advisory from failing ci:
    continue-on-error: ${{ matrix.checks == 'advisories' }}

    steps:
      - uses: actions/checkout@v2.4.0
      - name: Set up rust-cache
        uses: Swatinem/rust-cache@v1.3.0
        with:
          key: deny
      - uses: EmbarkStudios/cargo-deny-action@v1.2.10
        with:
          command: check ${{ matrix.checks }}

##[debug]Search path '/usr/local/cargo/registry/index'
Warning:  The "path" argument must be of type string. Received type undefined

To me that looks like a string but I also don't even know where this error comes from exactly.
I'd appreciate any help, thank you.

[Swatinem]

I think the problem might indeed be that some actions run in docker, and their artifacts do not leave the docker image. And "artifacts" in this case would be anything that is outside of the workspace.
I wonder if it would be possible to just move the CARGO_HOME into the workspace. As in $workspace/.cargo_home or something. NOTE that .cargo is already being used for workspace-local configuration.

Though I have heard that docker volumes might not be the most performant, but its worth a try.