regclient
Introduce GoReleaser
Fixes issue
#280
Describe the change
Standardized way of releasing to GitHub Creates Brew releases automagically
There are some TODO items, questions and shabby parts in this PR that need further discussion.
How to verify it
Not yet verified. I need to be able to execute GitHub Action workflows to verify the solution works. Acceptance criteria for the test would be:
- Artifacts have been published to a Brew tap and are downloadable and usable out of box for Mac users
- The existing Release Format/Artifacts are not affected. The binaries, file names and their contents, Metadata archive (for serving generated SBOMs and signatures), release notes header/body generation remain the same.
Changelog text
Introduce GoReleaser
Please verify and check that the pull request fulfills the following requirements
- [ ] Tests have been added or not applicable
- [ ] Documentation has been added, updated, or not applicable
- [ ] Changes have been rebased to main
- [ ] Multiple commits to the same code have been squashed
Thanks for working on this. It's been on my list to revisit goreleaser. A few goals I have are to test against older versions of Go (for anyone using regclient as a library), consolidating compiler options to a single location, and including the security metadata (signing and SBOMs). If we can't do these yet with goreleaser, then perhaps in the short term, we can split the brew build into a separate job, with the goal to consolidate builds on goreleaser later.
Hello, thanks for the feedback
A few goals I have are to test against older versions of Go (for anyone using regclient as a library)
I have deleted that section just to speed up and simplify the development process for this feature branch.
consolidating compiler options to a single location
With the introduction of goreleaser we can probably do away with artifacts/% make rule. For replacing bin/%s goreleaser might be an overkill.
and including the security metadata (signing and SBOMs)
That is also one of my pain points with goreleaser. The existence of signing and SBOM capabilities do not add much value if there is not any mechanism to archive and publish them. (There are after hooks but it is in GoReleaser Pro).
If we can't do these yet with goreleaser, then perhaps in the short term, we can split the brew build into a separate job, with the goal to consolidate builds on goreleaser later.
Looking at the PR again I think this might be a better way forward. I actually wanted to do this first, but the capability to publish prebuilt artifacts is not supported by the free tier of GoReleaser. That means we might have to duplicate the build process just to have artifacts on a brew tap, which is simply wasteful.
Looking at the points we have made so far, I am not sure if GoReleaser is the answer to this problem at all.
I will tag the participants in the original discussion to have a look at these points.
Thanks for the feedback again and cheers.
@developer-guy I think you were the one being pinged. 😄 (See the comments above.)
I spent a bit of time looking over the GoReleaser docs today, and I don't think I'll be adding it to this project. There's a lot of redundancy with code that is already in the Makefile or scripted in ways that I don't think would be trivial to migrate. It also adds another layer of abstraction to understand and track the development in case of breaking changes.
A lot of the need for GoReleaser has also been provided by community maintained packages of the project: https://regclient.org/install/#community-maintained-packages