I'm glad they're doing this, and it's an unpleasant surprise that they didn't already work this way. I don't understand why they allow mutable releases.

I think the only thing that would fix this issue is for them to lose 20%+ of their customers to a competitor. Something very simple that can vacuum up the GHES migration archive and proceed as if it were 2018 again.

I'd be willing to completely sacrifice actions, project boards, copilot, et. al. if it meant I could have ultra fast views into code, issues and pulls. I really see no reason the PR view cannot be pre-rendered on the server when the branch is pushed each time. This should be an instantaneous response at review time. I don't care if it's 5 megabytes of diff - If my browser can handle the react slop, it can certainly handle a big chunk of static DOM.

If I have anyone's attention there is something related I would like to see

Please add a small thing which users can look for on the public: repo/actions page

This small thing should let users know the action was run by github like is default and not run on a custom / private action runner

The private action runner feature makes sense but many projects tell users to look to the github action history to trust that tests A, B, C passed. If the github action ran on a private action runner then you really cannot trust that what is in e.g. run.yml actually ran

The attestation feature can be used to prove that an action was run by github and not by private / custom but users need to install the github cli to validate attestations and this is a heavy ask when I think an addition icon on repo/actions page or a diff icon color will do better

To alleviate the issue of mutable releases I had set up a mirror of releases checksums to be able to detect releases alterations. This is not needed anymore for immutable releases.

And automatically publishing checking of releases artifacts is also a good recent change by GH: in that project mentioned above I have developed a cli downloader checking the checksums of the downloaded file [1], but to be useful, it required the project to publish checksums, and the project to be mirrored. Now both of these requirements are dropped and the tool is readily useful for all GitHub immutable releases.

1: https://github.com/asfaload/asfald/

On the face of it, this seems like a non-starter. If a particular immutable release represents a danger to the consumer (extreme example: the software contains a bug that could result in physical injury) one must have the ability to retract that release so that no further consumers of the software could be affected by it. It makes sense that a retraction of an immutable release should not be reversible in such a way that the release could be recreated with different contents. But retractions must be possible, for both ethical and legal reasons.

I would also argue that its not sufficient to simply apply a blanket "deny all" access control to dangerous releases (assuming such a mechanism exists), as this does not adequately convey the deprecating nature of the change (and as a result, could mistakenly be reversed in the future). Ideally the retraction itself would be immutable such that once retracted the release is inaccessible forever.

Now, it may be that all this is supported by the new feature; I haven't had the chance to test it yet. But nothing in the documentation makes this clear one way or another.

        uses: github/codeql-action/init@8a06050a8c0348fb4738f28e0cfbb6727cf054ce # v4.31.2

        uses: github/codeql-action/init@0499de31b99561a6d14a36a5f662c2a54f91beee # v4.31.2

Microsoft does not have strict third party code review policies internally, has been hit with supply chain attacks before, and will be hit again. Consider this a nice to have feature, but give it zero trust.