-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Attempt to use github immutable releases #11901
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
alexcrichton
merged 1 commit into
bytecodealliance:main
from
alexcrichton:immutable-release
Oct 21, 2025
Merged
Attempt to use github immutable releases #11901
alexcrichton
merged 1 commit into
bytecodealliance:main
from
alexcrichton:immutable-release
Oct 21, 2025
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[Immutable Releases] look to be a relatively new feature on github which is a natural fit for us where we have no need to modify release assets after creation. My failed attempt to enable this earlier turned out to, expectedly, not work. This commit is an attempt to make things work. Specifically releases are now created as a draft initially, then release assets are attached, and finally it's automatically marked as a non-draft. While one could make a reasonable argument that a human should be involved in making the release a non-draft there's also something nice about just hitting merge on a PR and letting the release ride through CI. [Immutable Releases]: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases
Member
Author
|
And full disclosure, I've no idea how to test this JS so I haven't tested this. My plan is to issue 38.0.2 with this as a trial run. Probaby 38.0.3 as well once something inevitably goes wrong. |
pchickey
approved these changes
Oct 21, 2025
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Oct 22, 2025
This is an attempt to fix a bug with bytecodealliance#11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
Merged
github-merge-queue bot
pushed a commit
that referenced
this pull request
Oct 22, 2025
This is an attempt to fix a bug with #11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Oct 22, 2025
This is an attempt to fix a bug with bytecodealliance#11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Oct 22, 2025
This is an attempt to fix a bug with bytecodealliance#11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Oct 22, 2025
This is an attempt to fix a bug with bytecodealliance#11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Oct 22, 2025
This is an attempt to fix a bug with bytecodealliance#11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
alexcrichton
added a commit
that referenced
this pull request
Oct 22, 2025
* Attempt to use github immutable releases (#11902) [Immutable Releases] look to be a relatively new feature on github which is a natural fit for us where we have no need to modify release assets after creation. My failed attempt to enable this earlier turned out to, expectedly, not work. This commit is an attempt to make things work. Specifically releases are now created as a draft initially, then release assets are attached, and finally it's automatically marked as a non-draft. While one could make a reasonable argument that a human should be involved in making the release a non-draft there's also something nice about just hitting merge on a PR and letting the release ride through CI. [Immutable Releases]: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases * Fix release script (#11906) This is an attempt to fix a bug with #11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
alexcrichton
added a commit
that referenced
this pull request
Oct 22, 2025
alexcrichton
added a commit
that referenced
this pull request
Oct 23, 2025
* Attempt to use github immutable releases (#11902) [Immutable Releases] look to be a relatively new feature on github which is a natural fit for us where we have no need to modify release assets after creation. My failed attempt to enable this earlier turned out to, expectedly, not work. This commit is an attempt to make things work. Specifically releases are now created as a draft initially, then release assets are attached, and finally it's automatically marked as a non-draft. While one could make a reasonable argument that a human should be involved in making the release a non-draft there's also something nice about just hitting merge on a PR and letting the release ride through CI. [Immutable Releases]: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases * Fix release script (#11906) This is an attempt to fix a bug with #11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
alexcrichton
added a commit
that referenced
this pull request
Oct 23, 2025
* Attempt to use github immutable releases (#11902) [Immutable Releases] look to be a relatively new feature on github which is a natural fit for us where we have no need to modify release assets after creation. My failed attempt to enable this earlier turned out to, expectedly, not work. This commit is an attempt to make things work. Specifically releases are now created as a draft initially, then release assets are attached, and finally it's automatically marked as a non-draft. While one could make a reasonable argument that a human should be involved in making the release a non-draft there's also something nice about just hitting merge on a PR and letting the release ride through CI. [Immutable Releases]: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases * Fix release script (#11906) This is an attempt to fix a bug with #11901 where for 38.0.2 a draft release was made but it wasn't published due to a bug, so hopefully it'll be less buggy next time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Immutable Releases look to be a relatively new feature on github which is a natural fit for us where we have no need to modify release assets after creation. My failed attempt to enable this earlier turned out to, expectedly, not work. This commit is an attempt to make things work. Specifically releases are now created as a draft initially, then release assets are attached, and finally it's automatically marked as a non-draft. While one could make a reasonable argument that a human should be involved in making the release a non-draft there's also something nice about just hitting merge on a PR and letting the release ride through CI.