Hey @Link- , completely understand the points you're making here, but I don't think the extent of this change has been communicated clearly enough given the breaking changes this is introducing. The deprecation notice on the Github blog here uses the headline that v1-v2 are deprecated, and the paragraph below says that versions prior to 4.0.0 are closing down.

To me, this suggests that as long as I am using >= v4.0.0, my workflows won't be impacted. This discussion page instead suggests that I need to be on the very latest 4.2.0 release and that all other versions from 4.0.0 to 4.1.2 are now deprecated. This is a significant breaking change for anyone with security critical workflows who are pinning by SHA instead of floating version - and the main announcements do not make the extent of the deprecation obvious.

@rasa-jmac - I believe in addition to the changelog posts, these announcements & the brown-outs we're planning, we have sent out at least 2 email communications regarding this deprecation that clearly state the versions that will remain supported. We acknowledge this is a big change & we're doing the best we can to spread awareness as much as possible.

From my personal experience with deprecations, I'm afraid it's never the right time to do them no matter how much communication we send out.

I think I see the source of the confusion now - it was not immediately obvious to me that the versioning of the @actions/cache package is different to the actions/cache action. I'm not sure this is something that will be apparent to users who consume the action but aren't familiar with building their own actions using the package. It's easy to parse this messaging as "as long as my action is >4.0.0 everything will be fine"

That's a fair point @rasa-jmac and I can understand the source of confusion. It's a distinction that is very difficult to reason about especially since the names of the package and the action are the same.

That's also why the announcement here is different than the announcement in the package repo: actions/toolkit#1890

It's easy to parse this messaging as "as long as my action is >4.0.0 everything will be fine"

Can confirm this is exactly what happened when I read this error message and looked at the linked announcement. Note we also made sure to upgrade everything v4 in February already that was not v4 already.

Error: This request has been automatically failed because it uses a deprecated version of actions/cache: 6849a6489940f00c2f30c0fb92c6274307ccb58a. Please update your workflow to use v3/v4 of actions/cache to avoid interruptions. Learn more: https://github.blog/changelog/2024-12-05-notice-of-upcoming-releases-and-breaking-changes-for-github-actions/#actions-cache-v1-v2-and-actions-toolkit-cache-package-closing-down

6849a6489940f00c2f30c0fb92c6274307ccb58a is v4.1.2

From a user perspective we are just interacting with the tags (or commit shas) of the repo so reading <4.0.0 is automatically gonna be interpreted as tags <4.0.0. The text in the announcement linked in the error message is confusing from a user perspective.

Thanks @NicholasEllul - this is on our radar & we're working through it.

I'm afraid we cannot be more verbose in our communication

I appreciate the communication, but the blog posts and emails actually do not mention that some versions of 4.x are also deprecated, such as 4.0.2. They do mention "1" and "2" as being deprecated, and specifically "before 4.0.0".

Please consider updating the blog posts to say that you must use v3.4.0, v4.2.0, or the symbolic names v3 or v4. This would have saved a lot of back and forth from our teams.

It's hard, but yes, i think you could have (and still can) be more verbose - please take this as constructive criticism.

Is it possible to fix the deprecation message when the run fails? That would be really helpful.

I'm afraid we cannot be more verbose in our communication

I respectfully disagree and would like to propose these changes to your communication:

• adjust the error message to This request has been automatically failed because it uses a deprecated version of actions/cache: vX.Y.Z. Please update your workflow to use v3.4.0/v4.2.0 of actions/cache before March 1st, 2025 to avoid interruptions.
• In the linked blog post (https://github.blog/changelog/2024-12-05-notice-of-upcoming-releases-and-breaking-changes-for-github-actions/#actions-cache-v1-v2-and-actions-toolkit-cache-package-closing-down) you state versions prior to 4.0.0 will be closing down - adjust this to 3.4.0 and 4.2.0
• In addition I would suggest mentioning explicitly in the blog post that version 4.1.1 will stop working, even though being a very recent release

@tkloht Just noting that it's Feb 11th, 2025 right now - past the 1st.

right, updated 🙏

although I guess february 1st is accurate since we definitely have interruptions

@theUpsider your workflows started failing because you are using the tag v4.1.0 of SonarSource/sonarqube-scan-action that in turn is using the deprecated tag v4.0.2 of actions/cache:
https://github.com/SonarSource/sonarqube-scan-action/blob/1b442ee39ac3fa7c2acdd410208dcb2bcfaae6c4/action.yml#L35
After an upgrade to the latest version of SonarSource/sonarqube-scan-action your issue should be fixed.

@JoannaaKL @Link- Thanks for looking into this. Will update Sonarqube.

If the problem is recurring, please open a support ticket and share the workflows affected & we will have a look at it. If it's a public repository, feel free to share a link here. Thank you for reporting this.

It's a private repo. I've created an issue here.

The text in the blog post specifically mentions before v4.0.0, 4.0.2 is of date 19 march 2024. The check is wrong.

@michieldondorp actions/toolkit is not affected by the brownouts. Workflows that were failed above were using a deprecated version of actions/cache.

Hi @chaithanyaangalagunta - workflows using deprecated versions of actions/cache were blocked only during announced brownout dates. Please share a link to your workflow run or more details describing what kind of issues are you experiencing so that we can help. :)

@chetbox done, please try now

I have retrieved the latest cache file, thank you. 🙏🏼 Will I need to be restore the cache again when switched back to cache v2?

In the meantime I'll look into a backup system for this, or store the data somewhere that's designed for more persistent storage!

When I'll switch the flag for you again your repo is going to use the new cache service and your secret's won't be accessible anymore. You'll need to use values you saved now and upload them again. If you retrieved the cache I am switching you to the new backend. :)

Once I could see my cache list was empty I uploaded a new cache entry using a temporary branch upload-cache:

      - run: echo "RANDOM_SUFFIX=${RANDOM}${RANDOM}" >> $GITHUB_ENV
      - uses: actions/cache/save@v4
        with:
          path: .signal-cli-data
          key: signal-cli-data-${{ env.RANDOM_SUFFIX }}

Then deleted the branch:

$ gh push origin :upload-cache

Now I can see the singular new cache entry:

$ gh cache list

ID        KEY                        ...
20599463  signal-cli-data-256722088  ...

But, when running a workflow which is designed to fetch the latest cache with a matching prefix,

    - run: echo "RANDOM_SUFFIX=${RANDOM}${RANDOM}" >> $GITHUB_ENV
    - uses: actions/cache@v4
      with:
        path: .signal-cli-data
        key: signal-cli-data-${{ env.RANDOM_SUFFIX }}
        restore-keys: |
          signal-cli-data-

it cannot find any cache items with this prefix:

Cache not found for input keys: signal-cli-data-829215335, signal-cli-data-

What have I done wrong?

This setup worked fine with cache v1. According to the the docs I believe this should still work.

I worked it out! The cache I uploaded from my temporary branch is only scoped to that branch.

The cache is scoped to the key, version, and branch. The default branch cache is available to other branches.

-- https://github.com/actions/cache#cache-scopes

Instead I created a commit on my default branch, main, that uploads a new cache entry. This is available to restore from all branches and now my caches are restored successfully.

For anyone who wants to understand this further, see https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache for more info on cache scope restrictions.

@ulidtko don't mean to hijack this thread, but I am curious about the setup of the reusable workflow.

• Is it a reusable workflow in the same repository referenced using local path
• Is it a reusable workflow in another repository?
• Is it a reusable workflow in the same repository but referenced via @ syntax?

The cache key and version are calculated by the cache package client side (meaning within the actions/toolkit code, and there have not been any changes to that), but the scope is determined by the reference in the Actions Runtime Token JWT issued by GitHub.

My gut feeling here is that there is a corner case in how the V2 Cache backend API is validating the JWT to determine scope. This might cause the backend to think that the workflow running on the tag isn't a child of the default main branch.

If you could create a minimal reproduction of this scenario using a public repository I'm happy to look into this as well.

Thanks @AdnaneKhan 🙏 I understand that the toolkit hadn't seen change; but what you're saying, does make sense. As far as I can reason without deep-dive into the backend, of course.

I reproduce this even in non-reusable workflow. The requirements seem to be:

1. Caches created on non-default branch. (In my case, major-version-line branches like release/4.x, release/5.x, etc)
2. Tag-triggered workflow. Even when tag == branch tip, caches created on that branch fail to restore.

... Here, I've minimized a repro. https://github.com/zoomin-software/github-actions-cache-repro/actions/workflows/test.yaml

Notice 2 facts: first, caches exist:

— and second, actions/cache@v4.2.3 claims Cache not found for input keys, anyway:

LMK if I should try to explain more, and/or create a different issue clarifying the repro.

@ulidtko -

1. I advise you to read more about the cache restrictions: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache TLDR; you cannot restore caches across tags no matter what they point to if they're scoped to a tag. In that cache UI you should see the scope associated with your cache entry.

2. The only cache entry that can be restored in the run you referenced in the screenshot is the one you uploaded in ACME Release, version v0 because it's scoped to your default branch. BUT, that one has a key CI-cache1.r0.#4.attempt#1 and as such it will not be picked up by the prefix matching on CI-cache1.r1 nor will the other entries because they are tied to other scopes that are not shareable between runs.

@Link- I've carefully re-read this docs yet again, but still failing to understand:

• if a cache was created by a push/merge event on non-default branch release/7.9 — i.e. has got the scope release/7.9,
• immediately, the tip of this very branch gets tagged, with say v7.9.5,
• and this tag get pushed to github — triggering a run of version release workflow,
• do I understand correctly that this workflow run has scope refs/tags/v7.9.5 ? and there's no way to reuse cache from the prior branch-push build, the one with scope release/7.9 ?

I hope I'm wrong; because this design is so weird: most tag-triggered workflows run exactly once, on version release, and never again. It's useless to allocate dedicated caching scopes per every tag. Isn't it?

Am I missing a way to "customize" what a workflow's caching scope is?

What's the point of this "logical separation", could you explain the logic? 2 workflows building exact same commit with exact same code, cannot share cache?

Here, quoting the docs you linked:

Multiple workflow runs in a repository can share caches. A cache created for a branch in a workflow run can be accessed and restored from another workflow run for the same repository and branch.

— this seems to say that my workflow should be working.

And before recent updates, it did!

Can you try an experiment like this:

• Mirror the actions/cache repository (using repo import feature)
• Use the SHA of the 4.0.2 action but point to your mirror, not actions/cache.
• Try to replicate your tagging behavior.

This will hit the old v1 backend (and hopefully not auto fail) because that is still live until sometime in April.

If it “works” the that means the old functionality working was a result of the V1 cache backend not respecting the cache boundaries fully in the case of tags.

The change is going to be backported to the major versions of these actions:

actions/setup-dotnet	v3
actions/setup-go	v4
actions/setup-go	v3
actions/setup-go	v5
actions/setup-java	v3
actions/setup-java	v4
actions/setup-node	v3
actions/setup-node	v4
actions/setup-python	v4
actions/setup-python	v5

What that means is that a new minor release is going to be cut so that these actions are capable of integrating with the new backend and then the major version tags will point to these new minor releases.

For example:

actions/setup-node v3 currently points to actions/setup-node v3.8.2. A new v3.9.0 release will be cut and v3 will point to that.

Same applies for the entire list above.

The change is going to be backported to the major versions of these actions:

actions/setup-dotnet	v3
actions/setup-go	v4
actions/setup-go	v3
actions/setup-go	v5
actions/setup-java	v3
actions/setup-java	v4
actions/setup-node	v3
actions/setup-node	v4
actions/setup-python	v4
actions/setup-python	v5

What that means is that a new minor release is going to be cut so that these actions are capable of integrating with the new backend and then the major version tags will point to these new minor releases.

For example:

actions/setup-node v3 currently points to actions/setup-node v3.8.2. A new v3.9.0 release will be cut and v3 will point to that.

Same applies for the entire list above.

Thank you - is this planned for v2 of setup-node as well or will that be deprecated now?

We didn't see heavy usage from v2. Is there a particular reason why you're using it?

Thanks @optyfr - but you shouldn't be running on 2.319.1. If you want to manage your own runners, please make sure you keep them up to date: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners#controlling-runner-software-updates-on-self-hosted-runners