Deprecation Notice - Upgrade to latest before February 1st 2025 #1510
Replies: 2 comments 6 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.
-
|
Great to hear about the improvements moving forward, but what about all of the existing branches/tags. Won't they stop working unless the use of |
Beta Was this translation helpful? Give feedback.
-
|
Believe me, we've gone through this journey many times (with the artifact actions, node upgrades, runner images etc.) and I fully understand the cost of having to update workflows across several orgs and potentially thousands of repos to point to the latest releases. We did not take this decision lightly at all. Our telemetry indicates that the vast majority of workflows are already pointing to |
Beta Was this translation helpful? Give feedback.
-
|
Definitely appreciate that maintenance of software is hard, but as a crucial piece of infrastructure for open source and large private use cases, shouldn't GitHub be striving to keep the ecosystem healthy and functional rather than orphaning large swaths of software with a minor point release that breaks all existing builds that are practicing good software hygiene with locked down versions? |
Beta Was this translation helpful? Give feedback.
-
|
That's what we did. There were until this day users using |
Beta Was this translation helpful? Give feedback.
-
|
Definitely understand killing off support for |
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.
-
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 February 1st, 2025.
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