I’ve been watching the releases on GitHub closely for a bit, and this week did not see a lot of new releases, but there was certainly something interesting.
GitHub usually is good about giving us advanced notice before changes come out. How they rolled out Ubuntu 22.04 was a great example of this. There are also other things like Copilot, where there was an extended beta period before it became a product.
This week was a bit different. GitHub is updating the default GITHUB_TOKEN permissions to read-only in GitHub Actions. Before you get too worried, this is designed only to impact new repos, org, and enterprises. Existing repos, orgs, and enterprises will not have any changes, and new ones can enable the write permissions if they want.
Switching the default for the tokens to read-only is good, but it would be messy if they did not grandfather in existing repos. That said, if you work on one of those grandfathered repos, it’s still worthwhile to move to read-only tokens by default.
GitHub also released another change that impacted existing projects, and I suspect it caught many people by surprise. The January availability report briefly mentions it, but we’ll have to wait till next month’s report to get all the details.
On Tuesday, January 30th, GitHub released a change that could change the checksums for some git archives. They eventually reverted this change, and the availability report identified this as a 7-hour outage.
Looking at the timing of that notice going up, I doubt they realized this would happen. Their first reaction was to mention in the changelog that they do not guarantee the stability of checksums in autogenerated archives. If you are looking for a guarantee, the archives you upload are guaranteed to have identical checksums.
After quickly scanning the documentation for Releases, I did not find mention of the caveat around checksums and autogenerated artifacts, but I easily could have missed it.
There is a lot to learn from this. GitHub had an unexpected change made while updating a dependency. Their first reaction was to announce the difference and tell us they didn’t guarantee the functionality. Eventually, they rolled that change back, presumably because of complaints. Next month they will tell us more about what happened in their availability report.
I can’t say that I liked the initial announcement of the change, but GitHub has continued to address the issue with transparency, which I appreciate.
Would your team handle a similar situation as well?
Dan Cook 