GHA to create releases #170
Conversation
|
Can you give some background on the savings here on starting a GH workflow vs publishing release in GH? |
rodrigozhou
force-pushed
the
rodrigozhou/gha-create-tag
branch
2 times, most recently
from
9f9428a to
4aa4088
Compare
|
@cretz Remove potentially some mistakes when releasing a new tag like forgetting to set as latest. Also, with this workflow, we can trigger it whenever the |
To confirm, today's approach is:
But this new approach is:
So you save a single click, but now you have two more GH workflows to maintain and the user can still mistakenly click release in api/api-go? If we're concerned about users reading release process documentation and may not properly make one of the two releases, how can we know that they will read the documentation to know not to use the GH release feature but instead manual workflow dispatch instead? Are we saving much or just adding GH workflows to maintain? |
|
We can further remove the ability of manually triggering the release in |
rodrigozhou
force-pushed
the
rodrigozhou/gha-create-tag
branch
from
4aa4088 to
4e20b6d
Compare
josh-berry
dismissed
their stale review
Validation added for sdk-go in another PR. Thanks Rodrigo!
.github/workflows/create-tag.yml
Outdated
| CREATE_RELEASE: ${{ github.event.inputs.create_release }} | ||
| BASE_TAG: ${{ github.event.inputs.base_tag }} | ||
| run: | | ||
| if [[ -n "$(git tag -l "$TAG")" && "$(git rev-parse "$TAG")" != "$(git rev-parse HEAD)" ]]; then |
There was a problem hiding this comment.
I think we want to be even stricter here and make sure we're not skipping versions. At that point, I'd write a Go script to do the validation though.
There was a problem hiding this comment.
But I wonder if there will be a case in which you want to release a patch for a previous version.
There was a problem hiding this comment.
I think patches are acceptable but I've never seen us issue them.
.github/workflows/create-tag.yml
Outdated
| BASE_TAG: ${{ github.event.inputs.base_tag }} | ||
| run: | | ||
| gh repo set-default ${{ github.repository }} | ||
| gh release create "$TAG" --verify-tag --latest --generate-notes --notes-start-tag "$BASE_TAG" |
There was a problem hiding this comment.
Let's create the tag here and publish a draft. I would rather have a human in the loop to verify and edit release notes.
There was a problem hiding this comment.
I wonder if making it a draft will re-introduce the human error of forgetting to publish the release.
There was a problem hiding this comment.
No, because there won't be a tag until the release is published AFAICT.
| fetch-tags: true | ||
| submodules: true | ||
|
|
||
| - name: Validate input |
There was a problem hiding this comment.
We should also validate that the version given here matches the api submodule version. I think we should verify that there is a release or maybe a draft referencing the api submodule commit with the same version given as input to this workflow.
What changed?
GHA to create releases.
If a release is created, it also creates a PR in the consumers of api-go for review.
Why?
Automation.
How did you test it?
Potential risks