improve build

[bretello]

I noticed that version information had been broken for a while. This was fixed in #411 (thanks!), but I would like to avoid having to manage custom build arguments to accomplish this when goreleaser is available.

This PR does that:

• goreleaser.yml: add uptermd-fly rule
• Dockerfile.uptermd: use goreleaser to build binaries
  This simplifies the build process:
  • no passing around of build args as env vars
  • ldflags are only defined in .goreleaser.yml
  • always use the same method for building binaries
• goreleaser.yml: get rid of docker ids and --target arguments
  • uptermd binary is now being built in the docker image with goreleaser
  • goreleaser-specific stage has been removed
• Makefile: add goreleaser-build target (helps getting local builds out)
• gha: simplify build process (adapt it to the changes above)

[bretello]

Note: --auto-snapshot automatically sets --snapshot if the repository is dirty, this happens if:

• files are modified
• untracked files are present

Here's what versions look like (docker build -f Dockerfile.uptermd -t uptermd . && docker run --rm uptermd version)

Repo is clean (no modifications, no untracked files):

Uptermd version 0.19.0
Git commit: 522ecd5085d8998d72bfa3f63c04fb53e5cbcd77
Build date: 2025-11-30T13:29:39Z

Repo is dirty (untracked files are present):

Uptermd version 0.19.1-snapshot
Git commit: 522ecd5085d8998d72bfa3f63c04fb53e5cbcd77
Build date: 2025-11-30T13:29:39Z

[bretello]

Although this makes it easier to build docker images using docker build, this makes it much harder to build the images defined in .goreleaser.yml:

From the goreleaser docs:

Note that we are not building any go files in the Docker build phase, we are merely copying the binary to a scratch image and setting up the entrypoint.
The idea is that you reuse the previously built binaries instead of building them again when creating the Docker image.
The build context itself is a temporary directory which contains the binaries and packages for the current platform, which you can COPY into your image.
A corollary of that is that the context does not contain the source files. If you need to add some other file that is in your source directory, you'll need to add it to the extra_files property, so it'll get copied into the context.

Meaning that we either stop building images using goreleaser and the dockers: configuration in .goreleaser.yml or we skip changes in this PR altogether (making it harder to have correct version information in the binaries included in docker images).

Would like an opinion from @owenthereal before continuing.

[owenthereal]

@bretello:

I would like to avoid having to manage custom build arguments but I would like to avoid using extra build arguments to accomplish this when goreleaser is available.

Thanks for proposing this. Could you share more about the reasons you want to avoid managing custom build arguments?

One alternative is that we publish a upterm-fly Docker image with the version set similarly to the official image (ghcr.io/owenthereal/upterm/uptermd-fly:VERSION) and reference it in the fly.io manifest, as described here: https://fly.io/docs/blueprints/using-the-fly-docker-registry/#to-deploy-a-public-image-from-docker-hub-or-another-public-registry.

[bretello]

Could you share more about the reasons you want to avoid managing custom build arguments?

It's mostly about avoiding having to manually pass git information via build args when this information is available in the git repo itself (.git dir) and goreleaser parsing information this information already.