GoReleaser config and multi-platform image builds#1052
Conversation
Using GoReleaser simplifies the build process substantially, as it handles almost all the logic that needed to be in the makefile and the pipelines themselves. The one things that's missing from all this is a PAT to allow GoReleaser to push to ghcr.io. That means it fails here (which is expected): ``` ERROR: failed to push ghcr.io/goss-org/goss:latest: failed to authorize: failed to fetch anonymous token: unexpected status from GET request to https://ghcr.io/token?scope=repository%3Agoss-org%2Fgoss%3Apull%2Cpush&service=ghcr.io: 403 Forbidden ``` Adding a PAT called 'GITHUB_TOKEN' as a secret would allow this to work on the main repo. Owing to how GoReleaser works, I added something so that generating the .sha256 files for the {d,dc,k}goss scripts wouldn't cause GoReleaser to treat the repo as dirty. It also encourages building archives rather than attaching uncompressed binaries to releases. Incidentally, this means that the goss images are now built with SBOMs. It's straightforward to extend the configuration to also build packages and generate SBOMs for the release artifacts too. I believe this should mean the Travis CI pipelines can go away. I'd also note that the pipeline described by docker-goss.yaml is broken owing to aquasecurity/trivy-action's 0.24.0 tag no longer exists (likely due to the issues with and attacks on Trivy over the past few months). This new pipeline can do everything as far as release builds go, so I think that could be trimmed down to just a simple build of the master image on pushes to the master branch.
|
That Ubuntu integration test wasn't failing previously. I'm going to dig into it, but I'll have to wait until the weekend. |
|
The issues look to be mostly down to changes in test services and new OS releases that bumped some version numbers. There are a few dummy services (http in, for example) that look to either not be starting to not accessible. |
|
I investigated this while on the train yesterday. The issue appear to be because dnstest.io, which the integration tests rely on, is now parked. A sensible alternative would be to spin up something like dnsmasq internally and have it act as the resolver for the tests. dnsmasq can serve authoritative zones, and goss's |
|
My integration tests fixes work, and I've opened a pull request for them: #1061. |
1 participant
Checklist
make test-all(UNIX) passes. CI will also test thisDescription of change
Using GoReleaser simplifies the build process substantially, as it handles almost all the logic that needed to be in the makefile and the pipelines themselves.
As my repo is a fork and I've specified
ghcr.io/goss-org/gossas the image name, GoReleaser is (naturally) unable to push the final image, leading to the following expected behaviour:However, the 'GITHUB_TOKEN' secret should allow this to work on the main repo. This does at least show that it's able get through the multiplatform image build without issue.
Owing to how GoReleaser works, I added something so that generating the .sha256 files for the {d,dc,k}goss scripts wouldn't cause GoReleaser to treat the repo as dirty. It also encourages building archives rather than attaching uncompressed binaries to releases.
Incidentally, this means that the goss images are now built with SBOMs. It's straightforward to extend the configuration to also build packages and generate SBOMs for the release artifacts too.
I believe this should mean the Travis CI pipelines can go away.
I'd also note that the pipeline described by docker-goss.yaml is broken owing to aquasecurity/trivy-action's 0.24.0 tag no longer exists (likely due to the issues with and attacks on Trivy over the past few months). This new pipeline can do everything as far as release builds go, so I think that could be trimmed down to just a simple build of the master image on pushes to the master branch.
Incidental changes: