Closed reet- closed 1 year ago
Hi @reet- 👋🏽
This warning would only come when the cache doesn't exist and multiple jobs are trying to create the job.
The next time your workflow runs and looks for the same key, cache-hit
will be set to true as it will be found, so you shouldn't see these warnings given the jobs run before the cache is evicted.
This warning will also come with cache@v3
when the cache doesn't exist and there's a cache miss for all the jobs in the matrix the very first time and we have kept this warning for users to know that they're trying to create an already existing cache to let them know that cache is immutable.
To get rid of these warnings, you can modify your workflow to something like what our fellow action users are using - https://github.com/actions/cache/issues/901#issuecomment-1343377184
But again this is only needed if your workflows run rarely (i.e. after cache gets evicted).
Hi @kotewar
Thanks for your helpful reply.
This warning would only come when the cache doesn't exist and multiple jobs are trying to create the job. The next time your workflow runs and looks for the same key,
cache-hit
will be set to true as it will be found, so you shouldn't see these warnings given the jobs run before the cache is evicted.
Yes, I'm already using cache-hit
to avoid the warnings if an exact key hit happens on restore
, this works well. However, the warnings are always displayed when the default branch is updated:
save
the new keyThis warning will also come with
cache@v3
when the cache doesn't exist and there's a cache miss for all the jobs in the matrix the very first time and we have kept this warning for users to know that they're trying to create an already existing cache to let them know that cache is immutable.
Ah ok, thanks for the clarification, I missed that then.
To get rid of these warnings, you can modify your workflow to something like what our fellow action users are using - #901 (comment)
I don't exactly understand how this relates to my problem, can you please elaborate? In my case, the cache needs to be save
d since the exact key changes, and since all jobs are trying to do this in parallel, the warnings appear. I tried to use the gh-actions-cache
extension, but found it to be prone to a race condition (if performed in a separate step):
save
step intends to save, but another job already created the cache entry in the meantime -> warningI don't see any issue in your workflow since you're only saving on cache-hit
, but if there are cases where there will be changes in cache always, cache-hit
will be set to false
most of the times.
I don't exactly understand how this relates to my problem, can you please elaborate?
I just shared a use case where users are getting the cache created and stored in first step and in subsequent steps they are only restoring the cache multiple times. In your case, you are restoring cache multiple times, but saving is required only once, so multiple attempts of saving with same key will result in that issue.
the save step intends to save, but another job already created the cache entry in the meantime -> warning
This is the expected behaviour as all the save actions are trying to save the same cache. And these are just kept as warnings for users to know, the overall completion status is still success
.
I guess the behavior is expected, and this warning was not displayed when using cache@v3 directly. Is there a way to avoid/accept/silence it?
To answer your question, as of now, no there's no way to silence it.
Could I factor out cache saving into a subsequent job, not part of the matrix? What is the scope of the cache?
Could I factor out cache saving into a subsequent job, not part of the matrix? What is the scope of the cache?
I don't think this would be possible. The cache is scoped to its job only. However you can use upload-artifact and download-artifact actions to access data across the jobs.
Thanks @kotewar for your help. I think it is easier to just leave the workflow as-is and don't care about the warnings.
You are welcome @reet-. 👍🏽
And I'd very much agree its fine to ignore the warnings given the design of the workflow and the working of the action 😄
Hi,
I'm migrating an existing workflow from
cache@v3
tocache/restore@v3
andcache/save@v3
respectively. The aim is to only save the cache if on the default branch of the repository.Everything seems to work as expected, but multiple parallel jobs use the same cache, and this now leads to many warnings like the following:
See here for an actual workflow run: https://github.com/codelabs-ch/muen/actions/runs/4460336377
I guess the behavior is expected, and this warning was not displayed when using
cache@v3
directly. Is there a way to avoid/accept/silence it?Thanks reto