[chore] Update goreleaser used in CI to v2.3.2 #689
Merged
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.
The Github actions previously broke twice because of the release of goreleaser v2.3. I worked around this in PRs #667 and #676 by pinning the version used to v2.2.
After investigating, the causes of breakage were the following:
In v2.3, the amd64 architecture got a version specifier, which is "v1" by default, so the output directory changed from just "linux_amd64" to "linux_amd64_v1". Our PR workflow takes the output of the linux_amd64 build tests and uses it in the "package tests" job. Because of the change in directory name, the build output could not be found, the artifact upload failed silently, and the package tests failed loudly as they could not find packages to test.
In v2.3, the arm architecture changed its default version from "7" to "6". Our release CI never specifies this parameter when calling goreleaser, so it was now instructed to build for the arm_6 architecture, which we have no builds for in
.goreleaser.yaml
(only for arm_7). The prepare step thus failed silently, and the release step failed loudly as it can't find the artifacts for arm_7.This PR fixes these bugs and updates the goreleaser version to v2.3.2, by updating the expected directory name for the linux_amd64_v1 build outputs, and by specifying the $GOARM version parameter.
If we expect no such breakage to happen again, this would allow us to go back to using the latest version of goreleaser at all times, as suggested in #668.
I haven't tested the release CI yet for lack of a goreleaser pro key.