Our CI pipeline is a dockerfile that looks vaguely like this:
FROM golang:1.21 as build
go generate
go build
go test
FROM scratch
COPY --from=build ...
The CI steps are:
docker build <XXXX> && docker push <XXXX>
We have a goland project template that has options for generate, build, test that matches what we do in CI rather than having that _one_ edge case that is the difference between `make build` and `go build`. That difference has caused more than one outage in my career.
One example that comes to mind is building a single-binary full-stack application.
You can use whatever frontend framework you want, and just embed the html/css/js/asset files inside the binary with go:embed. In case of dynamic set of files, you can also write a Go utility to generate the embeddings with go:generate.
In addition to the ease of distribution (no more assets/ directory - just a single binary executable!), it also increases speed of the application, as it no longer has to perform file system reads in order to serve a webpage.
I've used go:generate to generate a set of structs based on an XSLT document. That said, since XML is fairly uncommon these days in popularity, the generator was a bit buggy still.
And I've used go:embed to include .sql files for database migrations and querying. I should really spend some time on this POC I made (sqlite, goose for migrations, and an implementation of temporal tables) and publish it as a demo.
Not OP, used embedded to add ebpf code compiled for a project, helps to only ship the binary.
Same thing for shipping swagger static html stuff to host an OpenAPI server.
We have a goland project template that has options for generate, build, test that matches what we do in CI rather than having that _one_ edge case that is the difference between `make build` and `go build`. That difference has caused more than one outage in my career.