Repository navigation
GoReleaser config and multi-platform image builds - #1052
Conversation
|
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. |
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.
|
Looks like the previous merge commit only failed because of unfortunate timing. |
|
Can you add a small note in the readme or in a new markdown file that explains how to run/test this without forking the repo and using GitHub? I assume it can be run with goreleaser locally for testing, right? |
|
Sure! Yeah, it can be run locally. All the configuration is in I'll update the documentation to make sure it covers this. |
|
It's probably best to merge #1068 before this, as there'll be a tweak needed to |
|
@aelsabbahy I've pushed up an example of how to built it with goreleaser. |
Additionally, this adjust the architectures to fit the goreleaser naming, which is closer to that of uname.
After #1052 was merged, I noticed some build failures with docker-goss.yaml. It turned out to have a few problems, some prexisting, and mostly caused by that PR, as I hadn't anticipated some of that pipeline's behaviours. It had logic for building the release image, but really shouldn't still have. I ought to have removed that as part of the #1052. I've trimmed it back to be just enough to handle pushing the image for Trivy to scan, which necessitated creating a dockerfile specifically for Trivy so it could be solved quickly. I'm in two minds when it comes to this pipeline. I think the weekly run of the most recent release image with `trivy-schedule.yaml` is probably enough, but I can see the value that also comes from scanning the HEAD of the master branch. This should make sure that merges to master no longer fail. Incidental changes: * It now only builds `linux/amd64`, though if this is an issue, I can partially revert it. This ought to be enough for Trivy though. In testing, I found `docker buildx` would hang during the image build, which is why I made the change. * Bump the version of Alpine: Trivy started flagging issues with the base image, so I figure there's no harm in getting both updated.
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: