Deprecation Notice - Upgrade to latest before February 1st 2025 #1510
Replies: 9 comments 62 replies
-
|
Is this really a deprecation? It feels like a very hard breaking change since it appears that all existing branches/tags will stop working unless upgraded. Is this harsh of a change really necessary? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
I think I see the source of the confusion now - it was not immediately obvious to me that the versioning of the |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
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.
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. |
Beta Was this translation helpful? Give feedback.
-
|
@Link- You may have seen the following blog post, or more recently the Ultralytics supply chain attack, both of which take advantage of the legacy cache service's behaviour to poison the cache of other workflows with malicious code. Will the newly built cache backend service include any improvements to mitigate these kinds of attacks? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @NicholasEllul - this is on our radar & we're working through it. |
Beta Was this translation helpful? Give feedback.
-
|
During the last brown-out, our builds failed even though we are only using v4.
Note in the error notice we are using |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I respectfully disagree and would like to propose these changes to your communication:
|
Beta Was this translation helpful? Give feedback.
-
|
@tkloht Just noting that it's Feb 11th, 2025 right now - past the 1st. |
Beta Was this translation helpful? Give feedback.
-
|
right, updated 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
although I guess february 1st is accurate since we definitely have interruptions |
Beta Was this translation helpful? Give feedback.
-
|
Is there some indicator that a workflow is using the new Cache backend or the old one? Based on the toolkit code there is a Is the new back-end only available during the brown-out windows, and workflows can ONLY use the old back-end until that hard switchover is completed later this month? I tried to force a workflow to use a new Cache backend by setting the environment variable and it failed to use the new Twirp RPC backend. I think it would be valuable to call out the specific URLs and endpoints used by the new one for anyone who is strictly monitoring egress from their self-hosted runners. |
Beta Was this translation helpful? Give feedback.
-
|
@theUpsider your workflows started failing because you are using the tag |
Beta Was this translation helpful? Give feedback.
-
|
@JoannaaKL @Link- Thanks for looking into this. Will update Sonarqube. |
Beta Was this translation helpful? Give feedback.
-
It's a private repo. I've created an issue here. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@michieldondorp actions/toolkit is not affected by the brownouts. Workflows that were failed above were using a deprecated version of actions/cache. |
Beta Was this translation helpful? Give feedback.
-
|
@Link- I have been facing cache related issues for the past couple of days sporadically. Is there any chance that these brownouts are causing issue for |
Beta Was this translation helpful? Give feedback.
-
|
Hi @chaithanyaangalagunta - workflows using deprecated versions of |
Beta Was this translation helpful? Give feedback.
-
|
I missed the the brownout periods and now my builds are failing. I have some very helpful data in the cache. Is it possible to recover data from cache v1, however manually? |
Beta Was this translation helpful? Give feedback.
-
|
@chetbox done, please try now |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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. :) |
Beta Was this translation helpful? Give feedback.
-
|
Once I could see my cache list was empty I uploaded a new cache entry using a temporary branch - 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: Now I can see the singular new cache entry: 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: What have I done wrong? This setup worked fine with cache v1. According to the the docs I believe this should still work. |
Beta Was this translation helpful? Give feedback.
-
|
I worked it out! The cache I uploaded from my temporary branch is only scoped to that branch.
-- https://github.com/actions/cache#cache-scopes Instead I created a commit on my default branch, 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. |
Beta Was this translation helpful? Give feedback.
-
|
We used version pinning, Issue: #1491 Cache entry from default branch considered out of scope for tag-triggered workflow. This deprecation causes complete failure of our CI. We can't upgrade to "the latest" — until viable workaround is provided (besides downgrading the action). Is there a way to "un-deprecate" v4.0.2 ? Perhaps only |
Beta Was this translation helpful? Give feedback.
-
|
@ulidtko don't mean to hijack this thread, but I am curious about the setup of the reusable workflow.
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 If you could create a minimal reproduction of this scenario using a public repository I'm happy to look into this as well. |
Beta Was this translation helpful? Give feedback.
-
|
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:
... 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,
LMK if I should try to explain more, and/or create a different issue clarifying the repro. |
Beta Was this translation helpful? Give feedback.
-
|
@ulidtko -
|
Beta Was this translation helpful? Give feedback.
-
|
@Link- I've carefully re-read this docs yet again, but still failing to understand:
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:
— this seems to say that my workflow should be working. And before recent updates, it did! |
Beta Was this translation helpful? Give feedback.
-
|
Can you try an experiment like this:
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. |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that the cache deprecation announcement called out third-party actions that use caching under the hood - but didn't explicitly mention first-party cache-aware actions. 
What does this mean for official actions like What will the failure mode look like in this case - just an error that the cache save/restore didn't work? Or is there a plan to cut a version bump to the v2, v3 of |
Beta Was this translation helpful? Give feedback.
-
|
The change is going to be backported to the major versions of these actions: 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:
Same applies for the entire list above. |
Beta Was this translation helpful? Give feedback.
-
Thank you - is this planned for v2 of setup-node as well or will that be deprecated now? |
Beta Was this translation helpful? Give feedback.
-
|
We didn't see heavy usage from v2. Is there a particular reason why you're using it? |
Beta Was this translation helpful? Give feedback.
-
|
And even actions that are using actions/cache@v4 stopped working with cache server 422 response code... until I realized that I need to upgrade my runners because I'm working with self-hosted runners! I was running 2.319.1 and upgraded to latest 2.323.0 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @optyfr - but you shouldn't be running on |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Context
The cache backend service has been rewritten from the ground up for improved performance and reliability. In latest versions actions/cache, we introduced a more consistent API contract with the cache backend service.
The new service will decrease the cache upload duration by up to ~80% when using GitHub Hosted Runners. The cache download performance will be the same. If you’re using self-hosted runners the upload duration is expected to improve, or in the worst-case stay the same. Cache upload/download performance depends on your network topology, hardware and geographical region used for hosting among other factors.
We will start rolling out the new backend service gradually as of February 1st, 2025. We will issue further guidance as we approach this deadline.
The legacy backend service will be sunset shortly after February 1st, 2025. We will not support both services at the same time. Refer to the migration guide below for further information on how to prevent disruption to your teams.
Migration guide
The new changes to the actions/cache should be seamless and fully backward compatible. You are not expected to change anything in your workflows to use the new service beyond upgrading to the latest releases.
In order to upgrade, edit your workflows to use one of these supported releases:
If you are caching or have forked these actions, please make sure you update your caches or your forks!
The following is the list of all the deprecated versions of this action. If you are using any of these version (or have pinned to any of their SHAs), your workflows will break as of March 1st, 2025.
Brownouts
To raise awareness of the upcoming deprecation, builds using deprecated versions that are scheduled to run during the brownout periods will fail. Planned brownouts schedule:
February 4, 5pm – 6pm UTC
February 11, 3pm – 7pm UTC
February 18, 2pm – 10pm UTC
Keeping your actions up to date with Dependabot
When you enable Dependabot version updates for GitHub Actions, Dependabot will help ensure that references to actions in a repository's
workflow.ymlfile and reusable workflows used inside workflows are kept up to date.Read more about that: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot#about-dependabot-version-updates-for-actions
GitHub Enterprise Server
This deprecation will not impact any existing versions of GitHub Enterprise Server that are currently in use.
Beta Was this translation helpful? Give feedback.
All reactions