pintohutch
commented
7 months ago LGTM, but shouldn't we do the same for rest of our cmds?
Maybe? Though I don't think we need to rush as those are electively deployed by users and not part of the managed suite of binaries. IMO they can be done later.
There might be a bit different perf characteristics with CGO, but recent resources says it should be minimal. Let's watch that with a bit more care (this is the most relevant to collector perhaps).
Thanks for the link - and good to know! I agree the collector is the most risky. I did some /prombench-marking for the PRs there 1,2,3 and they looked good for the most part. Agreed we should proceed cautiously to start.
cgo needs to be enabled to link against boringcrypto, so we add that here.
In addition, we use the google-go.pkg.dev/golang image as the Go buildbase to ensure build-time requirements, like boringcrypto, are enabled.
We also use gke.gcr.io/gke-distroless/libc as our runtime image.
We add the "cryp/tls/fipsonly" import to ensure boringcrypto is linking properly at build time. We guard this with a build tag "boring" in a dedicated file.