🚀 Immutable Releases Are Now Generally Available!

[tinaheidinger]

Immutable Releases are now generally available for all GitHub organizations and repositories!

This release brings a new layer of supply chain security to GitHub Releases by locking down release assets and tags after publication and generating signed attestations for every asset.

To get started, check out our changelog post and documentation.

We’d love for you to try Immutable Releases and share your feedback! Your input helps us polish the experience as we continue to invest in secure, reliable software distribution.

Let us know your questions, thoughts, and feedback in the discussion below. Thanks for helping us make GitHub Releases even more secure for everyone!

[maennchen]

This is a very welcome feature, but there’s a practical gap for projects that publish moving releases.

Many repositories (for example elixir-lang/elixir) publish immutable tagged releases alongside rolling ones, for example:

v<major>.<minor>-latest
main-latest

These intentionally update over time to track pre-release builds and nightly fixes.

Right now immutability is “all or nothing”, which breaks that workflow. What’s really needed is the ability to define an exclude pattern (similar to branch protection rules) so certain release name patterns remain mutable. Anything not excluded would be immutable by default, and previously published releases without an exclusion would stay immutable.

That would make the feature usable for projects that rely on both stable and rolling releases side-by-side.

[maennchen]

No, it’s just files to download. We’re already using cosign, but we’re interested to show that our actual release git tags are immutable and that feature would be great if it did not break the nightly releases we publish.

[sithlord48]

same with my project we use a continuous tag to release a always fresh pre-release as well as proper release only the v* tags should be immutable. Using a seperate repo is not an option. I am also making packages that users install. Looks like as is this feature is not usable in any of my projects. until i can pick what tags are immutable.

[xnox]

today in the UI there is no clear distinction between annotated tags & unannotated tags => probably somewhere the call was made to make all tags immutable, rather than treat signed tags differently.

[salbracco24]

Why publish a rolling release? I usually just publish a release with the semantic version, and then I have a tag like v1 which I move accordingly, but I don't use that tag in the release itself. It's basically what this repo does:
https://github.com/actions/checkout

[sithlord48]

Because it makes it much easier to have users test and help when they don't have to build everything on their own. We don't force people to use it but if someone finds a bug they can easily test with our current code before making a bug report.

Edit: we also have a stable tagged release. not just a rolling one.

[sithlord48]

Similar to the above comment

I see in the documents that draft releases are not immutable but it makes no mention of the pre-release releases.
Do pre-release releases become immutable as well?

[raulcd]

I tried this myself. pre-release releases are immutable too, you have to create them as draft releases if you want to add more artifacts to them. You can remove the draft mode once you are not going to update it anymore.

[xnox]

It would be useful to support on-the-fly attestation of the on-the-fly auto-generated source code tar.gz and zip:

• when download of auto-generated attestation is requested
• generate and temporarily cache the .tar.gz and/or zip
• attest them
• trigger multi-download of attestation and the tar.gz and/or zip
• discard at leisure

This way people can attest that auto-generated source code tar.gz and/or zip, was in fact github auto-generated.

[commonquail]

1. Enable immutable releases
2. Push annotated tag
3. Create and publish release
4. Disable immutable releases
5. Delete tag used to create immutable release
6. Reuse tag name for new tag pointing to different oid
7. Try to push new tag

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Release",
      "code": "custom",
      "field": "tag_name",
      "message": "tag_name was used by an immutable release"
    }
  ],
  "documentation_url": "https://docs.github.com/rest/releases/releases#create-a-release",
  "status": "422"
}

There appears to be no way to undo this state corruption. That tag name and release are now burned.

[xnox]

Good!

[paulmillr]

The implementation is deficient. Some GitHub events are not published correctly with immutable releases.

https://github.com/orgs/community/discussions/180177

[hfhbd]

How can you generate assets via GitHub Actions if you create a draft release via the WebUI? If I create a draft release via the webUI, GitHub Actions won't be triggered as stated in the documentation:

Workflows are not triggered for the created, edited, or deleted activity types for draft releases. When you create your release through the GitHub UI, your release may automatically be saved as a draft.

https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#release

So until now, you cannot use the webUI to create a draft release and use GitHub to generate the assets and make the release as released. Uploading the assets manually breaks the attestation.

[xnox]

@hfhbd i create draft releases with the github actions that uploads the assets; and then adjust the draft release as needed; and then mark it final. Does that help at all?

[hfhbd]

@xnox Only if you create the draft release via webUI and do not trigger the GitHub Actions run manually, yes. With mutable releases, all I needed to do is clicking on the releases and create a new release, without any draft releases or starting GitHub Actions manually.

As a workaround, I start my release workflow by pushing a tag instead, but you can't create a tag via the webUI, you need to use the git cli (or IDE).

[oSumAtrIX]

It looks like the tLogEntries are missing from release attestation, but artifact attestation includes it. The sigstore-java library requires tLogEntries