-
Notifications
You must be signed in to change notification settings - Fork 34
GHA to create release #170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Can you give some background on the savings here on starting a GH workflow vs publishing release in GH? |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a bit concerned about the maintenance of these two workflows for such an incredibly simple thing, but if y'all are resolving to maintain them and are now in full control of the release process of this and the API repo, ok.
4aa4088
to
4e20b6d
Compare
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think patches are acceptable but I've never seen us issue them.
8d00755
to
8ce9ea4
Compare
name: "Create release" | ||
|
||
on: | ||
workflow_call: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should discourage users from triggering this directly, could you add a note that will show up in the GH UI to encourage users to trigger the api
release instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is different from workflow_dispatch
. This is to allow calling from another workflow.
8ce9ea4
to
0b6e921
Compare
What changed?
GHA to create, publish and delete releases.
The workflow can only be triggered by another workflow (from
api
repo).Why?
Automation.
How did you test it?
Potential risks