Listen to this Post
GitHub is making significant changes to its cache service, migrating customers to a new system and decommissioning the old one. As part of this transition, the old cache service will experience brownouts, which could potentially disrupt your workflows. The deadline for fully shutting down the old service is set for April 15th, 2025. This article summarizes the critical information you need to ensure your workflows are not impacted.
GitHub Cache Service Brownouts
GitHub has begun the process of migrating its customers to a new cache service, with the old service scheduled to shut down by April 15, 2025. During this transition, GitHub will conduct brownouts of the old service to minimize disruption. However, users who are still interacting with the old service may experience failed workflows during these times.
The specific brownout periods are as follows:
- April 1, 2025: 3 p.m. – 7 p.m. UTC
- April 8, 2025: 2 p.m. – 10 p.m. UTC
If your workflows are still using the old cache service, be prepared for potential disruptions during these brownout windows.
Who Might Be Affected?
There are several scenarios in which users might still be utilizing the old cache service. If you’re experiencing failures during these brownouts, check if you fall into one of the following categories:
- Using Third-Party Actions or Products: If you are using a third-party action or product that relies on the cache service, you may need to update to the latest version. For example, actions such as mozilla/sccache, Mozilla-Actions/sccache-action, and Docker with GitHub Actions may be affected if they depend on the deprecated cache service.
-
Older Runner Versions: Users with a runner version older than 2.320.1 are still connecting to the old cache service and should upgrade to avoid issues.
-
Modified Environment Variables: If you’ve manually edited or removed any of the following environment variables, you might still be using the old service:
– `ACTIONS_CACHE_URL`
– `ACTIONS_RESULTS_URL`
– `ACTIONS_RUNTIME_TOKEN`
– `ACTIONS_CACHE_SERVICE_V2`
Deployment Permissions Update
Alongside the decommissioning of the old cache service, GitHub is also updating how deployment permissions work. Currently, users with the deployment: read permission can review, approve, or reject deployments. However, starting April 1, 2025, GitHub will require users to have the deployment: write permission to perform these actions.
If you are using fine-grained personal access tokens (PATs), be sure to update them to provide write access where needed. If this update is not made by the April 1 deadline, you will no longer be able to review, approve, or reject deployments.
What Undercode Says:
GitHub’s move to decommission the old cache service is an important step towards improving performance and aligning with modern infrastructure needs. However, the timing of these changes means that users must act quickly to ensure they don’t experience disruptions.
- Immediate Action Required: With the impending brownout dates, GitHub users should check their configurations and dependencies for any reliance on the old cache service. This is crucial for preventing workflow failures. Many users may not even realize they are still connected to the old service, especially those using third-party actions or older runner versions. For these users, updating to the latest versions or upgrading runner configurations will be necessary.
-
Update Permissions Early: The upcoming change in deployment permissions also demands attention. GitHub is giving a clear deadline, April 1st, for updating deployment permissions. Organizations should act swiftly to ensure their workflows are not interrupted by the new requirement for write access. Delays could mean the inability to review or approve deployments, a vital function for many teams.
-
Long-term Benefits: While these changes might be seen as an inconvenience, they are ultimately part of GitHub’s drive to modernize and streamline their platform. The new cache service promises better reliability and performance, and updating deployment permissions will provide more control over deployments, enabling fine-grained security measures.
-
Communication and Support: GitHub has done well to communicate these changes well in advance. Affected customers have been contacted via email, providing ample time to prepare. Teams should review their workflows, update their dependencies, and ensure their permissions are aligned before the April 1 deadline.
Fact Checker Results:
– Accuracy: The changes outlined in
- Impact: The brownouts and permission changes will significantly affect users who are still relying on outdated configurations.
- Timeline: The dates mentioned (April 1st and April 8th, 2025) for brownouts and April 1st for permission updates are correct and non-negotiable.
References:
Reported By: https://github.blog/changelog/2025-03-20-enhance-your-productivity-with-copilot-edits-in-jetbrains-ides
Extra Source Hub:
https://www.stackexchange.com
Wikipedia
Undercode AI
Image Source:
Pexels
Undercode AI DI v2
