Change release flow

[erikbosch]

This is a proposal to change the release handling somewhat

Today

• Create a tag and push to remote
• Trigger workflow on the tag and mention wanted version (e.g. 1.2.3)

If you trigger on branch you will get a faulty tag proposal in draft release that you must correct, tag will be created when release is published

After this PR

• Create a tag and push to remote
• Creation of release is started automatically

If you run the workflow on a branch you will get a release named after the branch, which you likely do not want

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 59.27%. Comparing base (30e5c13) to head (ef93e5a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #111      +/-   ##
==========================================
- Coverage   59.33%   59.27%   -0.07%     
==========================================
  Files          33       33              
  Lines       16067    16067              
==========================================
- Hits         9534     9524      -10     
- Misses       6533     6543      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lukasmittag]

Suggested change

	workflow_dispatch: # select tag when creating
	on:
	release:
	types: [published]

use this instead?

[erikbosch]

What would be the intended use case? We have an action further down in the script ( softprops/action-gh-release@v2) to create a release, and that becomes quite useless if we already have created a release.

And adding on:release is a bit superfluous. If you create a new release, and the tag does not exist since before a new tag will be created and that will anyway trigger this workflow.

I am actually considering if we should remove workflow_dispatch - I do not see that many use-cases for it, except possibly if you have yanked a release and want to rebuild a new release for the same tag.