-
Hi, My workflow looks like this:
The corresponding logs showed:
The post job logs show that cache was stored successfully:
However, on the second run, the cache is missed again. Logs here:
Does anyone have an idea about why the cache is being missed in the second run? Also, would it be apt to open an issue on https://github.com/actions/cache? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 24 comments 16 replies
-
@rj722 , I tested and tried as the demo you shared, but I did not reproduce the problem. Not sure what causes this problem. I have helped you report this ticket in the repository of the cache action: You can follow this issue ticket, and add you comment here. Of course, actually any user can directly open an issue this repository, that will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to help you solve the problems occur when you use this action, and also can collect and categorize your suggestions for this action. I think this is why the team will set the repository to be public. |
Beta Was this translation helpful? Give feedback.
-
@rj722 , I noticed the appropriate engineer has provided some suggestions for troubleshooting, please check with these:
|
Beta Was this translation helpful? Give feedback.
-
This doesn’t make sense to me. Seems like the cache should be dependent on the repo and the keys. Not on the branch. And in my experience, it only gets a cache hit on the same commit when I re-run the workflow. It never seems to get a hit even on the same branch. This is pretty silly. |
Beta Was this translation helpful? Give feedback.
-
Oh, so it’s scoped to the specific tag for runs triggered by a tag push as well. This is even more silly. It means that no tag build can use cache. Why do they scope it to the branch??? |
Beta Was this translation helpful? Give feedback.
-
Hey. How did you figure out it is scoped to the tag as well? |
Beta Was this translation helpful? Give feedback.
-
using cache on tags does not work
hi! I have a cache created on a non-default branch, all works fine except wh…en the workflow is run on a tag, the cache isn't hit when it's not a tagged commit, and my github.ref is "...heads" it starts working again. I guess it's related to https://github.com/actions/cache#cache-scopes Essentially, it looks like there is no way to use cache in runs on tagged revisions, or is it? (I don't have any caches on my master yet). Is it an intended behavior? At least, it'd be good if it was described in readme in that "scopes" section. |
Beta Was this translation helpful? Give feedback.
-
Makes no sense to cause a cache miss if it's from a non-default branch. That makes the cache much less effective. This essentially causes any workflow that you develop and presumably cache in a PR immediately cache-miss when it's merged into the default branch. The hash is guaranteeing a stable cache, regardless of branch.. I don't see the point for the branch protection as well. |
Beta Was this translation helpful? Give feedback.
-
This caching behavior should at minimum be configurable, if not straight up not branch specific. |
Beta Was this translation helpful? Give feedback.
-
Sure. That’s why we have cache keys. And fallbacks. Let the person
configuring the cache do that.
…On Fri, Mar 31, 2023 at 9:51 AM Andrew Porter ***@***.***> wrote:
Keeping things isolated by branch makes sense when you don't want the
cache in one branch polluting the cache in another branch. For example, if
I have a node project and I open a PR that adds, updates, or deletes a new
node module to the project, then someone else on my team opens a PR that
triggers the same workflow, a repo-level cache would likely cause issues.
—
Reply to this email directly, view it on GitHub
<#27059 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABLJIQBU5MIZMFMF6CIRJTW64DQXANCNFSM6AAAAAAQK2XZJI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I really dont see any improvement to use a cache inside the same branch, and that don't work with the default branch either ... only bullshit. |
Beta Was this translation helpful? Give feedback.
-
@partydrone A repository-level cache would likely cause issues. But not all people use the action just to cache node modules. There are many valid use cases. For example, I might want to use a production cache for the And even if it's a security vulnerability, it's not so high that it won't be even configurable. The discussion is running for 3 years without any response. |
Beta Was this translation helpful? Give feedback.
-
We have a real use-case where again circleci got it right and github got it wrong. We want to split tests by their times, so that each matrix runs more or less the same amount of time, think of it as a perfectly distributed tests per each instance of the matrix. If I am on |
Beta Was this translation helpful? Give feedback.
-
So what's the solution ? Is my understanding that for some arbitrary reason it won't run on
Is that correct ? |
Beta Was this translation helpful? Give feedback.
-
After doing everything fine, and even testing the cache manually in a test branch, the cache suddenly isn't being hit, what is going on? The cache is saved in a first run: Then, not hit for no reason: The two caches exists: And the action is configured like that: - name: Restore cached golangci-lint
id: golangci-lint-restore
uses: actions/cache/restore@v3
with:
path: ${{ env.GOLANGCI_LINT_CACHE }}
# search for golangci-lint-{commit} OR restore latest golangci-lint-*
# for the current branch or main branch
key: golangci-lint-${{ github.sha }}
restore-keys: |
golangci-lint- Anyone know what is going on? @BrightRan do you have any clues? |
Beta Was this translation helpful? Give feedback.
-
Is there any solution to this? It seems like people would like to configure the scope for cache but it also seems it's not configurable in any way. I've recently encountered this limitation myself as well. |
Beta Was this translation helpful? Give feedback.
-
@BrightRan as you guys can see many of us are pretty frustrated by not being able to share cache between branches. After 3 years, do you still not have a plan to add this functionality to the cache action? I should be allowed to set the branch restrictions, not you guys by default. |
Beta Was this translation helpful? Give feedback.
-
Seems clear to me that they are making money off of doing this and that is
a hard thing to just give up.
…On Wed, Sep 27, 2023 at 3:57 AM Oğulcan Çelik ***@***.***> wrote:
@BrightRan <https://github.com/BrightRan> as you guys can see many of us
are pretty frustrated by not being able to share cache between branches.
After 3 years, do you still not have a plan to add this functionality to
the cache action? I should be allowed to set the branch restrictions, not
you guys by default.
—
Reply to this email directly, view it on GitHub
<#27059 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABLJIRNOTWKP5JIKT2IG5DX4QBC7ANCNFSM6AAAAAAQK2XZJI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Handling cache hits at the repository level seems like a more sensible approach. We can easily customise cache keys by incorporating the branch's reference name into the key. The current default behaviour can be a bit confusing and unconventional or at least there should be a way to override this behaviour. |
Beta Was this translation helpful? Give feedback.
-
Classic GitHub stupidity. It doesn't work for releases as it's always has a different tag which means no cache hit. It makes no sense. I used the hash of |
Beta Was this translation helpful? Give feedback.
-
Thank you for this gigantic resource waste by design |
Beta Was this translation helpful? Give feedback.
-
interesting design choice! |
Beta Was this translation helpful? Give feedback.
-
Based on everything that's been discussed above, it does look like it might just be better not to use actions/cache, but implement your own, where you store caches in an S3 bucket or something. 🤷🏻 |
Beta Was this translation helpful? Give feedback.
-
That’s bound to be much slower.
…On Wed, Apr 3, 2024 at 6:25 AM Adrian Smijulj ***@***.***> wrote:
Based on everything that's been discussed above, it does look like it
might just be better not to use actions/cache, but implement your own,
where you store caches in an S3 bucket or something. 🤷🏻
—
Reply to this email directly, view it on GitHub
<#27059 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABLJIRGJ3B536P6FRSOG73Y3P7LFAVCNFSM6AAAAAAQK2XZJKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DSOJXGEZTI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
@rj722 ,
I noticed the appropriate engineer has provided some suggestions for troubleshooting, please check with these: