jade-guiton-dd
commented
1 month ago @songy23 I don't think so. That PR updates the version of goreleaser used in the tool that generates the .goreleaser.yaml files, but upgrading to v2.3.2 doesn't seem to require changes on that front, only in the CI workflow files.
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.