Closed noahehall closed 9 months ago
@noahehall
I noticed the same behaviour of the chaching Action in a Rust project. Caches are not restored. I assume that this might have happened due to changes in the new version 3.3.1. Thus, I believe that this issue addresses the same bug as #1151. And after all, this bug seems to be critical as a core functionality of the Action does not work anymore: restoring saved caches.
@kevinmatthes indeed
the actions/cache@v3
works within a workflow, i havent tested cross workflow, and it doesnt seem appropriate in this case as I need to distinctly save, then restore across workflow runs whereas cache@v3
always does a save && restore when executed
i was going to try to migrate to artifacts but the docs say artifacts are not available across workflow runs
as a workaround I just rerun the documentation step on failure of restore
I am getting cache fetch failures in the same workflow:
The cache is occasionally fetched, occasionally not. I am also getting sporadic hanging of tests when code is fetched from the cache. Not sure if it is related directly but the tests only hang when the cache fetch succeeds.
I also came here to say that my cross-Workflow cache retrievals are failing where they were previously succeeding. Both Workflows use the same container, so I don't think the containers are the issue.
Following discussion with github support, the inclusion of the zstd
in ubuntu github runners causes a discrepancy between custom containers and what is expected in the cache. Adding this package to our custom containers has so far fixed the issue:
RUN apt-get update && apt-get install zstd ....
Shout out to Joseph from GH support who was the contact point for this resolution.
I have requested that this gotcha be added to the actions container documentation.
@mark-jordanovic-lewis will test after work today
[update]
unfortunatly that did not work for me
@noahehall
I have tried to fix the cache issue in my Rust project and ended up in avoiding the cache Action completely by applying a suitable workaround. In my use case, I needed to store a downloaded and compiled Rust binary such that I did not have to compile it on every workflow run. The solution to this specific problem was to apply a GitHub Action that installs exactly that binary I need.
For your use case, @noahehall, I also thought about possible workarounds. One option might be to upload the compiled documentation as an artifact at the end of the first workflow and to download this artifact during the second workflow. I know a project which uses this technique in order to create a test result comment on PRs. The use case of that project seems to me analogous to your use case: create some data in a first workflow and upload it as an artifact, download and process the data in a second workflow. They use actions/upload-artifact@v3 for the upload and a custom shell script for downloading and processing of the data at the same time. Would this option be suitable for your use case?
@kevinmatthes thanks for the tip; will try this weekend.
This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.
This issue was closed because it has been inactive for 5 days since being marked as stale.
in workflow 1: create docs and save to cache using source branch name![image](https://user-images.githubusercontent.com/10324554/232244779-4abb900c-5e4f-449c-bd68-d78ea01dff7b.png)
in workflow 2: restore cache using source branch name and commit![image](https://user-images.githubusercontent.com/10324554/232244807-aba72873-9d63-4e02-a75f-a2c7f2cb4a10.png)
as you can see, workflow 2 does not find the cache