Use GitHub's CLI gh to publish releases

[ivanvc]

What would you like to be added?

In an effort to improve automation in the release process, I want to open the discussion of automating step 7 from the release guide. In my experience by participating in the release process, this is one of the most involved steps.

I think we could automate it by using gh release create. We could start by drafting a new release, eliminating the step of copying and manually editing the release text, and uploading the resulting artifacts. Then, we could keep a manual step of publishing the release while verifying that the draft looks correct.

Why is this needed?

Work towards improving the release process. Although I would like to have way more automation, I feel it's a good compromise to start by taking small steps toward full automation.

[ivanvc]

cc. @jmhbnz @ahrtr @serathius. Please let me know your thoughts.

[serathius]

#13980 as reference for previous work in this area.

[ahrtr]

Thanks for the proposal and sounds good to me. Do you have a PoC PR?

[ivanvc]

#13980 as reference for previous work in this area.

@serathius, I love the idea of having it automated after we push a tag (as I think we also discussed during one release). But I also see that as far-fetched and still needs some more investigation. As we're now part of the Kubernetes organization, there are some challenges that we've been seeing with automated jobs that need to publish stuff to GitHub.
That all to say that I'm aligned with your thinking :)

Thanks for the proposal and sounds good to me. Do you have a PoC PR?

@ahrtr, not yet. I wanted to hear your opinions before implementing it.

[jmhbnz]

Thanks for creating the feature issue @ivanvc. I am completely supportive.

In future we will move away from manually running scripts to having prow jobs (as GitHub Actions token permissions are too restrictive under k8s enterprise org).

In the short term further automation for the manual steps we currently perform is a great idea and will help the transition to prow jobs long term.

[ivanvc]

/assign

As we're all aligned, I'll go ahead and draft a PoC PR.

[bavarianbidi]

Sorry for being late on this discussion 🙈

On auger i've created a PR to use goreleaser for creating a release (etcd-io/auger#136).
Probably goreleaser for doing a release might be also an alternative?

If wanted i can also do a PR to show how goreleaser would act in this case - WDYT?

[ivanvc]

Thanks for the initiative, @bavarianbidi. Although I think it'd be a good idea to use goreleaser for etcd, the build process (and script) is a bit more complex, as it also handles the release of Docker images. I think this would make sense later, but I aim to take small incremental steps to improve the release process. Currently, a known pain is that the last step is manually building the release on the GitHub site, which this issue (and associated pull request) addresses.

[bavarianbidi]

Thanks for the initiative, @bavarianbidi. Although I think it'd be a good idea to use goreleaser for etcd, the build process (and script) is a bit more complex, as it also handles the release of Docker images. I think this would make sense later, but I aim to take small incremental steps to improve the release process. Currently, a known pain is that the last step is manually building the release on the GitHub site, which this issue (and associated pull request) addresses.

Thanks @ivanvc for the fast reply.
I totally understand your approach with small incremental steps. goreleaser is quite good in creating container images, binaries, ... in one step. Will try to dig a bit deeper in the current release process of etcd and probably raise a draft PR to demonstrate it.

[ivanvc]

Thanks @ivanvc for the fast reply.
I totally understand your approach with small incremental steps. goreleaser is quite good in creating container images, binaries, ... in one step. Will try to dig a bit deeper in the current release process of etcd and probably raise a draft PR to demonstrate it.

Sounds good, I also forgot to mention (and realized after reviewing your auger's pull request):

1. We're in the middle of a migration from GitHub actions to prow jobs, although it could make sense to keep some GitHub actions for equivalents that we wouldn't have in prow jobs
2. We don't have write permissions in the repositories through automation (prow jobs and GitHub actions). This is part of a recurring ask/conversation in the #github-management in the Kuberentes' Slack channel

Edit: Also refer to #13980 (comment), #17873

[bavarianbidi]

As etcd-io/auger#136 got merged, i can raise a draft PR for using goreleaser in here as well - if needed/wanted

[ivanvc]

Hi @bavarianbidi, I'd suggest first to start by following up on #13980 (comment) and #17873.

[ivanvc]

Setting the release as a prerelease or not the latest in a draft release does not seem to work as expected. I had success publishing the release using the CLI and setting the flags while running edit. i.e.,

gh release edit ${VERSION} --latest=false --prerelease=false --draft=false

I think after today's result, it should be fine to publish the release automatically. Alternatively, we could add a prompt so the release lead can open and review the draft. And when hitting enter (back at the terminal), it publishes it.