no cache found when using a tag as trigger #74
Comments
|
Which branches are used to generate or fetch the cache? The action is using the same mechanism as upstream: https://github.com/Swatinem/rust-cache#cache-limits-and-control |
|
I push the tags to the master branch, do I need to specify this somewhere? I turn on debug logging and investigate this further, thanks for the advice! |
|
When I rerun the job with debug logging enabled, it successfully restores the cache but I don't know why. The abbreviated logs are: |
|
When I create a new tag with debug logging enables, it fails to restore the cache again, with the following logs: |
|
I created a personal access token and queried my caches using the GitHub REST API with the following result: The "ref" field of the token contains the tag name, which is different for each new release tag. What is the purpose of this "ref" key? Could this cause the problem? It would explain why it only works when I rerun the job, where the tag is the same. However for my purpose this would never cache anything, as I don't commit the same tag multiple times except when rerunning a failed job. How can I work around this issue? |
KonradHoeffner
changed the title
|
I will try to workaround this issue by using a "push" trigger instead of "create". However that probably leads to missing functionality as I assume this will not trigger on manually created tags using the web interface. |
|
What refs/tags are available is rather a restriction of github itself related to permissions and security, nothing I can do on my end related to that. I notice however that you are using a rust nightly, which will not reuse caches at all if the nightly version happens to change in between. |
|
I use a fixed version of Rust nightly, and the problem occurs even on the same day, so that shouldn't be the reason. |
|
The second part of the key differs: {
"total_count": 9,
"actions_caches": [
{
"id": 9,
"ref": "refs/tags/0.0.12",
"key": "v0-rust-build-upload-23bec24e5dab7b55324e3f0372d66f277a7f8544-2228b0b78308ae915213e629a8ca0cdf1470726b",
"version": "f01be42591250bd35d7c7c4bd7e62a372a21bf52808a04fa8d4d19a904019b84",
"last_accessed_at": "2022-09-04T12:00:12.686666700Z",
"created_at": "2022-09-04T12:00:12.686666700Z",
"size_in_bytes": 225769805
},
{
"id": 8,
"ref": "refs/tags/0.0.11",
"key": "v0-rust-build-upload-23bec24e5dab7b55324e3f0372d66f277a7f8544-37d963d84b9c033e1ef948d4c4f8831739092353",
"version": "f01be42591250bd35d7c7c4bd7e62a372a21bf52808a04fa8d4d19a904019b84",
"last_accessed_at": "2022-09-04T11:47:08.860000000Z",
"created_at": "2022-09-04T11:47:08.860000000Z",
"size_in_bytes": 225777917
},That second part seems to be the lockfile hash, which is strange because I don't have a lock file: It seems as if the cache does not work at all without a lock file, but the documentation states there are limited benefits. Is that a bug or am I doing something wrong? |
|
According to #70 there is supposed to be a fallback but this does not seem to activate in my case.
|
|
When using a generic GitHub actions cache, adapted from https://ectobit.com/blog/speed-up-github-actions-rust-pipelines/, the same problem occurs. - name: Set up cargo cache
uses: actions/cache@v3
continue-on-error: false
with:
path: |
~/.cargo/bin/
~/.cargo/registry/index/
~/.cargo/registry/cache/
~/.cargo/git/db/
target/
key: ${{ runner.os }}-cargoIt now seems to me as if the "ref" attribute is the real culprit after all: {
"total_count": 10,
"actions_caches": [
{
"id": 10,
"ref": "refs/tags/0.0.13",
"key": "Linux-cargo",
"version": "4464b218375e2702da53c92c2e51ffdd3cdd5aeba23dec304d9c1239b4ef594a",
"last_accessed_at": "2022-09-05T07:24:51.066666700Z",
"created_at": "2022-09-05T07:24:51.066666700Z",
"size_in_bytes": 246555679
}, |
|
I'm closing this because I think it is a general problem with the underlying actions cache when triggered by a tag as the "ref" attribute is set to "refs/tags/..." instead of the branch name. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Even though the cache key is the same, GitHub does not restore the cache. What am I doing wrong?
Previous run post run log, see https://github.com/KonradHoeffner/rickview/runs/8167984956?check_suite_focus=true:
Current run log:
This is my
.github/workflows/release.yml:The text was updated successfully, but these errors were encountered: