Integrate goreleaser into repo

[timflannagan]

Description

Overview

This commit integrates the goreleaser tool into the repository. Previously, we were relying on the legacy buildbot / cloudbuilder tooling to generate and publish release artifacts for this project. As we iterate on this project, we have the opportunity to modernize our release process with tooling and workflows consistent with the rest of the Go ecosystem.

New Release Workflow

With these changes, a new release.yaml GHA workflow has been introduced, which is responsible for configuring and invoking goreleaser under-the-hood (via the release Makefile target). Additionally, this workflow enables the following event triggers:

• On Pull Requests to main: We ideally want to run a subset of the release pipeline on PRs to main or pushes to main to ensure our release pipeline isn't silently breaking until a new release needs to be cut.
• On New Tags: Automatically triggers a release when a new version tag is pushed.
• workflow_dispatch: Provides an escape hatch to run this workflow ad-hoc to help test changes or troubleshoot any issues with our release pipeline.

The workflow calls the make release target, which internally invokes the goreleaser CLI. While goreleaser provides its own third-party GHA, this approach helps ensure that local and CI environments use the same entry point. This consistency has the following advantages:

• Devs can troubleshoot goreleaser issues or test configuration changes locally without requiring changes to the workflow file.
• It simplifies testing by allowing changes to the goreleaser configuration to be validated locally before committing to source control.

For example, I could test out the full release pipeline works in my fork via the make release IMAGE_REGISTRY=ghcr.io/timflannagan IMAGE_REPO=k8sgateway VERSION=devel GORELEASER_ARGS="--clean --skip=validate" command.

Why goreleaser?

The goreleaser project helps simplify our release workflow while meeting our requirements:

• Builds and publishes multi-arch container binaries and images
• Generates release tags, release notes, etc.
• Integrates with GHAs well (i.e. it has it's own first-class action)
• Exposes knobs that allow users to configure which stages of the release pipeline are run (i.e. only build images, but don't generate release tags, etc.)
• Provides configuration options for attaching additional artifacts for a GH release

Additionally, there are several other features that we could explore adopting over time (e.g. artifact signing and SBOM generation).

Alternative - GHAs

An alternative approach to using goreleaser would be encoding the entire release pipeline directly within GHA workflow(s). While feasible, this approach has some trade-offs:

• Increased Complexity: Encoding multi-step workflows, such as multi-arch builds, container publishing, and artifact generation, may require custom bash scripts and extensive YAML configuration.
• Reduced Maintainability: Changes to the release process would require updating multiple workflow files, increasing the risk of errors or the risk of regressing the pipeline.
• Limited Reusability: GHA-based workflows are tightly coupled to CI/CD, whereas goreleaser configurations can also be run locally by developers, ensuring consistency.
• Lack of Built-in Features: Features like artifact signing, SBOM generation, and fine-grained control over pipeline stages would need to be implemented manually or ditched entirely due to the increased release workflow complexity.

While GHAs provide flexibility, goreleaser offers a purpose-built tool for releases, reducing maintenance overhead and aligning with industry best practices for the Go ecosystem, and allows us to simplify the GHA release workflow by delegating release steps to a known tool.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works

Closes #10443.

[timflannagan]

Renaming the image registry is causing the conformance suite to fail as our helm chart expects the quay.io/solo-io registry. I'm planning on fixing the helm chart + any other reference to this registry, but happy to do that in another PR if we want to keep these changes tightly scoped.

[yuval-k]

i think it's good to fix so we don't break conformance CI.

[lgadban]

I agree (I think), let's either no do any renaming yet or handle it all to not break conformance.
My preference is actually to not do any renaming in this PR but don't feel too strongly

[timflannagan]

@lgadban Agreed on holding off on any naming for now. I looked into doing this locally and it was a bit more involved than I would've liked. I'll do that renaming (adopting ghcr.io as the registry, renaming component images, etc.) in a follow-up and we can iron out what's best there.

[lgadban]

so when this PR merges we will begin releasing on every push to main?
also assuming we still need to configure GITHUB_TOKEN etc?

[lgadban]

I agree (I think), let's either no do any renaming yet or handle it all to not break conformance.
My preference is actually to not do any renaming in this PR but don't feel too strongly

[timflannagan]

so when this PR merges we will begin releasing on every push to main?

@lgadban I held off on this after the convo about exhausting runner budget in the free org with doing that. IMO I'd like to see us do that once the initial release GHA workflow is checked into the repo.