Use GoReleaser to build binaries #16
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This replaces most of the manual workflow steps. GoReleaser config tweaked to match the current release filenames. Signed-off-by: Matt Dainty <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the change
This PR changes the build process to instead use GoReleaser to build the release binaries.
Benefits
I use this action to automatically install tools from GitHub releases into my GitHub Actions workflows. It works mostly ok with your existing releases, downloading the latest release that matches the OS and architecture my workflow is running on, however because the binary within the release archive still has the OS and architecture as part of the filename, I have to make sure my workflow runs
wait-for-port-$(uname -s)-$(uname -m | sed -e 's/x86_64/amd64/' -e 's/aarch64/arm64/')to ensure portability instead of justwait-for-port.While I was trying to work out the cleanest way to change the binary filenames, I figured it would be just easier to use GoReleaser instead which is a popular tool for building Golang-based releases. This removes a lot of the boilerplate from your existing workflow. It also creates the releases for you with the changelog entries, etc. so you just need to push the new version tag.
Supporting more OS/architecture combinations is also easy to change by just updating the
.goreleaser.ymlconfiguration file.Possible drawbacks
Anyone expecting the previous behaviour of the binary having the OS and architecture as part of the binary filename.
Applicable issues
Additional information
I've tuned the GoReleaser configuration so it creates release tarballs and checksums with the same filenames as previous releases.
I've disabled Cgo which means static stripped binaries are built as standard. Contrary to the comments in #9 the size of the binaries is almost exactly the same as the dynamically-linked versions, about 2 MiB so this means things will work on Alpine.
I've also updated the some of the actions to their latest versions, I'd recommend maybe enabling Dependabot to keep these updated.