feat: publish pre-built binaries with releases

[takumin]

Motivation

Recently, I noticed that httpbin.org was unstable and CI was failing often.

I wanted to take advantage of the great implementation in this repository, but my CI environment doesn't support Docker or Go, so I thought it would be convenient to be able to download static binaries.

About

• Introduced .github/workflows/build.yaml for CI/CD, including build, checksum, and publish jobs
  • Supports Go cross-compilation for multiple OS/arch targets
  • Includes artifact attestation and checksum generation
  • Publishes artifacts to GitHub Releases on tag push
• Extended Makefile with release target to generate static binaries per target
  • Supports GOOS/GOARCH/GOARM detection and naming

Notes

To check the operation, we issued a test release in the following repository and confirmed that it works properly.

Repository:
https://github.com/takumin/go-httpbin

Commit:
takumin@857d10f

GitHub Action Workflow Log:
https://github.com/takumin/go-httpbin/actions/runs/14769067526

Test GitHub Release:
https://github.com/takumin/go-httpbin/releases/tag/v2.18.2

[mccutchen]

Thanks for the contribution, this kind of prebuilt binary release process is long overdue!

Before I dive too far into the code itself, I have a couple of high level questions:

• Why is the new workflow split into separate build/checksum/publish jobs? It's not obvious to me at a glance why this isn't one job, but if I had to guess I'd wonder whether it's simpler to separate the build job (with its large matrix) from the rest of the steps, which can operate on all of the built binaries at once without needing to duplicate the matrix.
• Did you consider using GoReleaser for this? That's what I've had my eye on for a while, with their example-supply-chain repo as an enticing example. Basically, I think we could do everything you've got here and more with a declarative configuration and off-the-shelf GH Action workflows.

[mccutchen]

One more high level question:

• Does this build binaries for every commit on a pull request and/or every push to the main branch? It seems like it might, but it's not obvious to me. I'd rather just build binaries like this when a new release is tagged, and leave it to intrepid developers to build themselves if they need a pre-release version.

[takumin]

Thank you so much for your kind review!
I forgot to say thank you first.
Thank you for providing us with such a great software.

• Why is the new workflow split into separate build/checksum/publish jobs? It's not obvious to me at a glance why this isn't one job, but if I had to guess I'd wonder whether it's simpler to separate the build job (with its large matrix) from the rest of the steps, which can operate on all of the built binaries at once without needing to duplicate the matrix.

This is a matter of personal preference.

I didn't like the fact that a checksum file was generated for each binary when merging jobs.

However, this is just my personal preference, and your opinion should take precedence over the rest, so I have no problem with merging the jobs.

• Did you consider using GoReleaser for this? That's what I've had my eye on for a while, with their example-supply-chain repo as an enticing example. Basically, I think we could do everything you've got here and more with a declarative configuration and off-the-shelf GH Action workflows.

Yes, I used GoReleaser for a few years for both work and personal OSS, but in the end I came to the conclusion that it would be easier to maintain if I didn't use it.

Because GoReleaser is a tool that handles build infrastructure, you will want to use various functions as you use it, but most of the useful functions are paid plans.

This is not a problem when using it for work, but for personal OSS activities, the question of who will bear the costs arises.

So what about the free version's functions? It just hides the functions I submitted in this PR, which seems convenient at first glance, but it's the worst when you encounter an edge case.

As mentioned above, various functions are hidden and black-boxed, so the burden on maintainers is heavy when analysis is required.

Still, everything is a balance, so of course it is important to consider introducing it while taking into account the trade-offs.

I respect your opinion on this matter as well.

• Does this build binaries for every commit on a pull request and/or every push to the main branch? It seems like it might, but it's not obvious to me. I'd rather just build binaries like this when a new release is tagged, and leave it to intrepid developers to build themselves if they need a pre-release version.

Speaking from experience, CI that only runs release builds has a high probability of failing (and this is extremely subjective).

The reason is that if you run CI on a regular basis, you can detect when there's a problem right away, but things often "silently break," so as someone who values ​​the flow of working smartly, releasing, making a coffee, and taking a breather, I've come to take the stance that it's better to run the release process partially on a regular basis and "find out that CI is broken as soon as possible."

On the other hand, I cannot deny that this is a very down-to-earth approach, so as always, I respect your opinion to the fullest extent.

[mccutchen]

Thanks for the detailed reply, I appreciate your thoughts here.

I hope to dig in this weekend, I’ll keep you posted!