feat: Add ko build for Go Releaser

[appkins]

This pull request updates the container image build and release pipeline to use the ko tool instead of Docker Buildx, and refactors how image names are generated and tagged. It also introduces several configuration improvements for reproducibility and clarity in the release process.

Build and Release Pipeline Modernization:

• Replaces Docker Buildx and QEMU setup steps with ko-build/[email protected] in both .github/workflows/ci.yaml and .github/workflows/release.yaml, simplifying the workflow and enabling native Go container builds. [1] [2]
• Updates container registry login to use ko login instead of the Docker login action for consistency with the new build tool. [1] [2]

Image Naming and Tagging Improvements:

• Refactors the default IMAGE_NAME in .goreleaser.yaml to derive the image name from the Git repository URL, making it more flexible and less hardcoded.
• Changes image tagging logic to use latest only for non-snapshot builds and introduces a more descriptive sha-<commit> tag for main branch builds.

Release and Snapshot Configuration:

• Adds a snapshot section to .goreleaser.yaml to generate snapshot versions with a -next suffix for pre-release builds.
• Sets IS_RELEASE=true and updates GORELEASER_EXTRA_FLAGS to include --clean for release builds in the CI workflow.

Container Build Customization:

• Configures builds to use docker.io/chainguard/static as the base image, disables SBOM generation, and sets additional metadata such as creation time and supported platforms for reproducibility. [1] [2]

Minor Formatting and Consistency Updates:

• Normalizes YAML formatting, such as quoting checksums.txt and explicitly setting skip: false for builds.## Description

Fixes: #

How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:

I have:

• updated the documentation and/or roadmap (if required)
• added unit or e2e tests
• provided instructions on how to upgrade

[jacobweinstock]

Hey @appkins. Thanks for breaking this out. The description is very detailed about what the PR has changed. What I'm missing though is why all this is needed? For example, you say, "simplifying the workflow". Why was the workflow previously not adequate?

I tried this code out and found it was missing a few things that the existing code provides. These things are useful for local development. Building and pushing to local registries that can manually be defined. Also, the current configuration allows testing the release process locally.

• local image build. make build-image doesn't produce a container image locally. If i comment out disable: "{{ .IsSnapshot }}" in .goreleaser.yaml, I did get it to produce an image named: goreleaser.ko.local:v0.6.8-next and goreleaser.ko.local:bd1891e5012578fec3b04079266690bd358426e6dfa0028f64f7064d0703e0c2. I would have expected the second one to be image:sha-<short-hash>. And no latest tag was created.
• the image registry doesn't seem to allow overriding via env var. currently, REGISTRY=example.org make build-image or REGISTRY=example.org make build-image-push does this.
• the image name doesn't seem to allow overriding via env var. currently, IMAGE_NAME=testing123 make build-image or IMAGE_NAME=testing123 make build-image-push does this.

[appkins]

Hey @appkins. Thanks for breaking this out. The description is very detailed about what the PR has changed. What I'm missing though is why all this is needed? For example, you say, "simplifying the workflow". Why was the workflow previously not adequate?

I tried this code out and found it was missing a few things that the existing code provides. These things are useful for local development. Building and pushing to local registries that can manually be defined. Also, the current configuration allows testing the release process locally.

• local image build. make build-image doesn't produce a container image locally. If i comment out disable: "{{ .IsSnapshot }}" in .goreleaser.yaml, I did get it to produce an image named: goreleaser.ko.local:v0.6.8-next and goreleaser.ko.local:bd1891e5012578fec3b04079266690bd358426e6dfa0028f64f7064d0703e0c2. I would have expected the second one to be image:sha-<short-hash>. And no latest tag was created.
• the image registry doesn't seem to allow overriding via env var. currently, REGISTRY=example.org make build-image or REGISTRY=example.org make build-image-push does this.
• the image name doesn't seem to allow overriding via env var. currently, IMAGE_NAME=testing123 make build-image or IMAGE_NAME=testing123 make build-image-push does this.

Hey @jacobweinstock, these are some fair critiques that will require further effort on my end. I will make some time this week to address them all. The main functions I would like to include via this PR are image signing with cosign and streamlined CI/CD.

While Ko is not required for either of the above functions, I tend to use Ko in my golang projects. It simplifies the structure, removes Dockerfiles, etc. I'm happy to sideline this PR for now as I sort out some of the functionality elsewhere.

My main usage for the Tinkerbell project is a fairly large scale homelab environment that includes dozens of SBCs, Mini PCs and enterprise grade servers I've collected over the years. The bulk of the changes are actually in the tinkerbell project, which I have yet to make publish a PR.

It might be a bit pre-mature to work through all of the changes since I haven't completed testing on my end. I thought I would push up some of the lighter PRs first before raising the tinkerbell PRs.

Considering the scope of my changes, It might be best to sideline these two PRs for now and discuss down the road. The CI/CD changes mostly serve to unblock my forks so that I can run the Cluster API changes in my environment.

To give a brief summary of what I intend to submit shortly:

• TFTP optimization and rework (http style handler implementation)
• HookOS http server using upstream golang file server + OCI downloading
• U-Boot support for bootp file selection
• SBC support leveraging the existing HookOS images, but supporting pivots based on DHCP vendor info