GitHub supports Immutable Releases, which prevents changes to artifacts after a release has been made public.
Some projects manage their release lifecycle by splitting it into two tools. One tool manages release creation (e.g., release-please), and the other handles building and publishing (e.g., GoReleaser, cli-gh-extension-compile).
In such configurations, when the immutable release feature is enabled, it is common for the release management tool to create a tagged draft release, and for the build tool to upload artifacts to that draft release and perform the publication; however, this action does not support that workflow.
I propose a new use_existing_draft input (default: false) to address this.
When set to true, the action looks up the release for the tag, verifies it is in draft state (and fails clearly if not), uploads artifacts, then publishes it with gh release edit --draft=false.
GitHub supports
Immutable Releases, which prevents changes to artifacts after a release has been made public.Some projects manage their release lifecycle by splitting it into two tools. One tool manages release creation (e.g., release-please), and the other handles building and publishing (e.g., GoReleaser, cli-gh-extension-compile).
In such configurations, when the immutable release feature is enabled, it is common for the release management tool to create a tagged draft release, and for the build tool to upload artifacts to that draft release and perform the publication; however, this action does not support that workflow.
I propose a new
use_existing_draftinput (default:false) to address this.When set to
true, the action looks up the release for the tag, verifies it is in draft state (and fails clearly if not), uploads artifacts, then publishes it withgh release edit --draft=false.