use goreleaser to build binaries on tagged releases

[displague]

Description

• Adds GoReleaser and a GitHub Workflow to run when tags are pushed.
• Binaries are created for several architectures and operating systems.

See https://github.com/displague/tink/releases for an example (based on this commit) of what a release will look like.

Future iterations could bundle these binaries with documentation as archive files, or build debs, rpms, Docker images, etc.

Goreleaser's own .goreleaser.yml is a handy demonstration: https://github.com/goreleaser/goreleaser/blob/master/.goreleaser.yml

Why is this needed

Fixes: #73

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

[gianarb]

Great work

During my past experience with GoReleaser and multi-arch support for Docker images, I can say that it is not easy to do in a clean way. At the end of the story, we didn't use it for other projects like packet-ccm or CAPP for that reason.

We have to support as part of the release workflow something that can build and push multi-arch Docker images as well, not only the binaries. And I would like to merge a PR that contains both

(DCO please)

[displague]

I've made changes to publish amd64 Docker images in the latest builds.

I'm testing changes to add arm64 and armv6/armv7 images.

[displague]

Hmm @gianarb, it looks like this would only be possible for goreleaser to push multiple architectures images using a separate Docker repository for each architecture (examples: tinkerbell/tink-server, tinkerbell/tink-server-arm64, tinkberll/tink-server-armv6, etc).

This is due to goreleaser/goreleaser#530

I see four options here:

• close this PR entirely in favor of another approach in the future. (no worries! this investigation is reusable elsewhere)
• create unique Docker repositories for each architecture (and publish binaries and docker images for all arch/os combos)
• build binaries for all arch/os combos and publish only amd64 Docker images (for now, using goreleaser)
• build binaries only, don't publish docker images for now

Which would you prefer?

[displague]

A differentiator between this project and packet-ccm/csi-packet is that this project benefits from providing tink-cli binaries where those other projects are primarily consumed as containers.

What binaries do Tinkerbell users need? Only tink-cli? Should tink-server and tink-worker only be provided as containers?

If we take adocker manifest or docker buildx pattern it would be nice to reuse the same binaries that are archived on release (one of the benefits of the goreleaser pattern). This would cut down on build resources and would ensure that the different execution methods are still close (using the same binary).

[gianarb]

We should not tight ourself to the idea that containers are the only one to run Tinkerbell because it is not true.
Tinkerbell today depends on Docker but I see docker as a Kubernetes CRI. Technically I am sure we can even use the same interface at some point.

Anyway, from this repo we should release tink-cli, tink-server, and tink-worker as binary + containers version of them in multi-arch and OS.

If we take adocker manifest or docker buildx pattern it would be nice to reuse the same binaries that are archived on release (one of the benefits of the goreleaser pattern). This would cut down on build resources and would ensure that the different execution methods are still close (using the same binary).

I agree and that's why I think docker + binaries should be part of the same PR because you will see how complicated it is to make with goreleaser. I saw you had a look at tinkerbell/proposals#5 , I will explain it with your comment but I think we should get there with one PR :).

Ideally (but I didn't write anything about it yet) to test a release process we can spin up a nightly release for tink (other repos will follow that will run as GitHub Action at a certain schedule)

[displague]

I see. Work in tinkerbell/proposals#5 should be allowed to finish first.

I'll close this PR in its current form (so others don't wait for this one and so they aren't prevented from trying alternate directions). I may revisit this.

a nightly release for tink (other repos will follow that will run as GitHub Action at a certain schedule)

I don't see the need for a nightly release. If we are using semver and pushing latest images from the default-branch (on every commit), what purpose do nightly binaries serve? I think the only reason nightly makes sense now is that we have not stamped a single tagged release. Why not just push 0.1.0 (#74) on all of the current projects in their current state?

This is probably a better conversation for https://github.com/tinkerbell/proposals/pull/5/files#diff-5ae2d202d9cad195081db97be153eaa9R139.

[gianarb]

nightly is just a very easy way to test the release process continuously with a short feedback loop