aclevername
commented
2 months ago Go Releaser investigation
Looking at goreleaser it acts upon the creation of a git tag, it doesn't create the tag for you. It will:
- create the binaries (multi arch)
- create a github release at the tag
- upload the binaries to the release
- add auto-generated release notes from commit history (can be customised) to the github release
- set an go ldflag for the version when building the binary so we can support
kratix-cli --versionwithout having to edit the code
We can use github actions workflow that already exists, or write it by hand in circleci (former is probably easier).
Release-please investigation
Looking at release-please it autogenerates a PR that is the placeholder of the next release. The PR contains release notes, and the PR is continually updated as new commits get pushed, example. The PR is created via github workflow. the release note generation is a bit more clever than goreleaser, it uses convention commit to filter out whats a feature by commits prefixed with feat:, and bug fixes from fix:. When you merge the PR (which just updates the CHANGELOG file) it:
- Creates a tag
- Create a github release from the tag, adds the release notes
image stolen from https://danwakeem.medium.com/improve-your-github-releases-10x-with-this-one-simple-action-56e59e46dd85
Release-please does not doing anything related to building code. They recommend you have other tooling that gets triggered on Github releases being created be responsible for uploading artifacts to the release. Rip grep is an example of a CI using Release-please that has a github action to trigger on a release being created, and then manually uploads the binaries.
Questions
- Does goreleaser and release-please play well together?
- it seems yes! Not much documentation, but a big project as an example to copy is k8sgpt cli. They use release-please to handle release notes and manual releases, and then delegate to goreleaser to upload the artifacts.
- are auto-generated release notes good enough?
- we could do a manual release process with manual release notes if we wanted.
-
do we want automatic or manual releases?
- if automatic, we can use the Kratix approach and do a release on every green run of
mainby pushing a new tag at the end of CI (if using goreleaser). Unclear how to do automatic releases with release-please, and tbh it seems against the point of it (issue open on the repo to support it) - if manual, we can manually push tags (if using goreleaser) or manually merge release-please PR (if using release-please combined with gorelease)
Proposal
We either:
- if automatic, we can use the Kratix approach and do a release on every green run of
- We use just goreleaser and auto create a new tag on every green commit to main (how Kratix does releases).
- enforce as a team we all use human-readable release-note-worthy commit messages when merging PR (can squash on merge if needed)
or:
- We use release-please and goreleaser combined (how k8sgpt cli does). Releases are manual by merging the PR, also gives us a chance to manually modify the PR release notes if we aren't happy with them (e.g. a bad commit history was merged)
There's currently no way to consume the Kratix CLI other than cloning and compiling the binary yourself.
Let's improve this by automatically creating releases of the CLI, so the users can download the compiled binary for their OS directly from Github.
We can use release-please with go-releaser to make the entire process very simple.