Would it be possible to "allow updates only for drafts and prereleases"?

[panayot-cankov]

This is the release cycle for one of my projects. I have multiple packages in a monorepo. For the release of any of the packages a new release branch is created and release dispatch workflow is triggered:

• Add commits with package version update, changelogs, etc.
• The workflow would build the package artefacts
• Create (or update for fixes) a draft release and attach the artefacts
• Run e2e tests
• Go to code freeze, have a release candidate, manual testing etc.
• On bug fixes, commits are pushed in the release branch, the old workflow is deleted and triggered again with the last commit (go back to 2 - build, update the draft etc.)
• Require approval for publish
• Upload the artefacts to a marketplace
• Update the draft to an official release, apply tags.
• Make a PR, merge any fixes in main

This plugin works really well, from my point of view, there only two things that are coming a bit short:

• Add a flag to allow updates only on draft and prereleases, and error the build when trying to update a release. Protect existing releases from being overridden from release builds triggered by mistake. Once things go to NPM there is no going back.
• By default the tags to target the current commit (the one that the git checkout would get) instead of the main branch.

  There is a commit option, that I will be setting for this, but wouldn't that be a bit more reasonable default?

[ncipollo]

Add a flag to allow updates only on draft and prereleases, and error the build when trying to update a release. Protect existing releases from being overridden from release builds triggered by mistake. Once things go to NPM there is no going back.

Hmm I think I understand the usecase but could you use allowUpdate instead to accomplish the release protection your are after (or the omit inputs to prevent your release from moving back to a draft)? This usecase seems a little specialized, I'm not sure it makes sense to add a new input for it. I think most people drive their releases from a tag being pushed (see the example in the readme). Tag pushes are a little harder to have accidentally happen (since we would need to force the update). Have you considered based your workflow on a tag push?

There is a commit option, that I will be setting for this, but wouldn't that be a bit more reasonable default?

The primary use case of the action is really to generate a release from a tag update. Generating a tag & subsequent release from a commit is a secondary use case (both in terms of the action & the Github API it relies upon). Therefor, I'm hesitant to default the commit to anything other than no value, since by default the action should use the tag if a tag-push triggered it.

There are other issues with using the current commit. Github will only create the tag & release once. So if you push another commit with the same tag it will do nothing.

[panayot-cankov]

allowUpdate won't help, the workflow should be allowed to update drafts, but not a release that "has shipped".

Is it really so rare to use release drafts to store release candidates for things like installers, extensions, etc? And if the RC needs some fixes - to keep updating the draft until the binaries are stable enough for a release, and then ship and convert the draft to a release?

I am about to use the github API to verify the state of the release, and probably use git to push the moved tag.

[Gwindalmir]

I hit the same issue, but for a different reason.

I forgot to update the version of my build, so when I went to run the new release build it automatically overwrote an existing release of that particular version.
I'd much prefer to only allow updates if the release is marked as a draft. My software is alpha, so I use pre-releases for actual releases until I reach a stable version.

IMO, once a release is Published, it should be immutable.

[AraHaan]

Well for me, when I create a release, there are sometimes where one would like to be able to "service" them.

[ncipollo]

Added updateOnlyUnreleased.

[panayot-cankov]

Thank you!