ci: Do release tagging in CI and add --draft support #5652
Conversation
2571b36 to
d52c639
Compare
3c4a2bf to
2449a80
Compare
Co-authored-by: Dean Sheather <dean@deansheather.com>
| # Cache commit metadata. | ||
| . ./scripts/release/check_commit_metadata.sh "$old_version" "$ref" | ||
|
|
||
| # Create new release tag. |
There was a problem hiding this comment.
nit: Is it possible to run the workflow for the same version twice? It happened to me a few times in the past that the release script broke down in the middle of releasing and I had to clean tags and artifacts manually before retrying. I'm curious if we need the safety mechanism here.
There was a problem hiding this comment.
It's a good nit. I was thinking we can use the GH actions concurrency keyword to ensure only one instance can run at a time: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
There was a problem hiding this comment.
To add to this, the tag_version.sh script will error if the tag already exists, meaning we can't re-run this on main if HEAD already has been tagged:
❯ git tag v0.14.2
❯ CI=1 ./scripts/release/tag_version.sh --ref HEAD --patch
Checking commit metadata for changes since v0.14.1...
No breaking changes detected, using "patch" increment.
Old version: v0.14.1
New version: v0.14.2
$ git tag -a v0.14.2 -m Release v0.14.2 f5d623ff
fatal: tag 'v0.14.2' already existsDoes this, combined with concurrency (meaning only one release can run at once) take care of your concern @mtojek?
There was a problem hiding this comment.
Yes, although more convenient behavior is to allow for multiple runs to perform missing actions. For example, if the first run didn't publish the release notes due to HTTP 500, the second can fix it.
There was a problem hiding this comment.
I see what you mean. I think that's fairly well addressed here since right now the critical part happens in "Publish release". If anything fails before the tag upload (GH release immediately follows), we can just restart the workflow.
I just realized it's possible to run the workflow for a specific tag, not just for a branch. If we need to in the future it should be fairly easy to modify it to not error in tag_version.sh if we're running it for a tag since most steps are repeatable.
I'll think about this some more, thanks for bringing it up.
This PR moves
git tagfrom users local machine to therelease.yamlactions workflow.We no longer automatically trigger a release on tag push, instead the workflow must be triggered via
./scripts/release.shor manually via workflow dispatch.We now also support providing
--draftflag to create draft releases.Example run via workflow dispatch: