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 |
cretz
left a comment
There was a problem hiding this comment.
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.
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.
8d00755 to
8ce9ea4
Compare
| name: "Create release" | ||
|
|
||
| on: | ||
| workflow_call: |
There was a problem hiding this comment.
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.
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
apirepo).Why?
Automation.
How did you test it?
Potential risks