improve build
I noticed that version information had been broken for a while. This was fixed in https://github.com/owenthereal/upterm/pull/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: adduptermd-flyrule -
Dockerfile.uptermd: use goreleaser to build binaries This simplifies the build process:- no passing around of build args as env vars
-
ldflagsare only defined in.goreleaser.yml - always use the same method for building binaries
-
goreleaser.yml: get rid of docker ids and --target arguments-
uptermdbinary is now being built in the docker image withgoreleaser - 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)
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.
@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.
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.