Go 1.18 BuildInfo support

[abhinav]

trafficstars

What version of rules_go are you using?

v0.30.0

What version of gazelle are you using?

6bbfc47f1b0a27ee1efeddcc6671f3e4e03235dc

What version of Bazel are you using?

Build label: 5.0.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Wed Jan 19 14:08:54 2022 (1642601334)
Build timestamp: 1642601334
Build timestamp as int: 1642601334

Does this issue reproduce with the latest releases of all the above?

Yes.

What operating system and processor architecture are you using?

% uname -sm
Linux x86_64

and

% uname -sm
Darwin arm64

What did you do?

Wrote a program that tries to access build information via runtime/debug.ReadBuildInfo and built it inside a Git repository.

package main

import (
	"fmt"
	"runtime/debug"
)

func main() {
	info, ok := debug.ReadBuildInfo()
	fmt.Println(info, ok)
}

What did you expect to see?

Information about the build environment.

What did you see instead?

<nil> false

[sluongng]

You would need to use bazel stamp feature in combination with rules_go x_defs instead.

It does not make sense to enable this in rules_go by default as it affect build hermeticity and ruin bazel cache pretty badly.

[ar3s3ru]

You would need to use bazel stamp feature in combination with rules_go x_defs instead.

It does not make sense to enable this in rules_go by default as it affect build hermeticity and ruin bazel cache pretty badly.

Hey @sluongng, would you mind providing more info on how to use this?

[sluongng]

Here you go https://github.com/bazelbuild/rules_go/blob/master/docs/go/core/defines_and_stamping.md#defines-and-stamping

[garymm]

Is it possible to have the default behavior of bazel build --stamp produce something that's usable with debug.ReadBuildInfo()? If not possible to make it default, it'd be nice if this were documented.

[garymm]

Was poking around to see how go build does it, found this: https://cs.github.com/golang/go/blob/245e95dfabd77f337373bf2d6bb47cd353ad8d74/src/cmd/go/internal/modload/build.go#L442

Still haven't looked at it long enough to figure out if it's feasible to replicate, or how, using rules_go.

[malt3]

Unsure if this should be a separate issue, but I think the solution cannot be stamping alone.

While I personally am happy to embed version info, timestamps and maybe a git commit via stamping, the BuildInfo contains a lot more than just this. When using go build, this will also place version info for all dependencies that end up in a binary (think go.mod / go.sum) into this buildinfo section. This info can be extracted using go version -m <GO_BINARY_FILE> or objdump -s -j .go.buildinfo <GO_BINARY_FILE> and can be used to generate SBOMs just from the binary alone. I feel like this is an important feature. It has also been around since go 1.13 so this part of the build info exists for far longer.

[sluongng]

@malt3 agree. The problem could be broken down into 2 parts:

1. The supply chain metadata (module, tool versions)
2. The build metadata (git revision, built time)

(2) is essentially Bazel's stamping.

(1) could be included in the binary while keeping it hermetically reproducible. This could be generalized as the "SBOM" effort currently on-going as part of rules_license. There is an initial attempt for the Go ecosystem at this over at https://github.com/bazelbuild/bazel-gazelle/pull/1315. I would recommend reading up on the discussion in that thread to understand the current state of things.

If you want to take a crack at this, here is a rough list of steps on top of my head: a. Enhance Gazelle's Go/Bazel language extension to generate package() targets with versioning metadata in compliance with rules_license. This would allow go_repository to emit their versioning during the build phase. b. Enhance rules_go to pick up the versioning metadata provided by rules_license / bazel's package() and include it in a new provider propagate through go_library and go_binary. c. Wire up the metadata in the new go provider with the flags provided in go tool compile and go tool link d. Add tooling versions as part of the provider/metadata/build process.

---

Even if you exclude the communication needed between the implementer and the Go team and the Bazel team, this is still a non-trivial amount of work. rules_go doesn't have a full-time maintainer right now to drive this effort.

Realistically, I think organizations who are interested in having this work completed to contact Bazel SIG to set up a proper bounty. This way it would attract part-time maintainers/contributors toward this feature. cc: @alexeagle

[fmeum]

I most likely won't be able to work on this, but can promise timely reviews.

@aiuto Could Google be interested in funding this effort through the SIG to bootstrap SBOM support?

[malt3]

Thanks for the compilation of relevant info / steps. At this point in time I cannot offer to work on this feature due to time limitations and my unfamiliarity with writing bazel rules.

I would be super happy to see this implemented but I understand that resources are missing to work on this.

[udf2457]

I am seeing this issue (or something very similar) with:

rules_go 0.46.0 gazelle 0.35.0 go_sdk 1.22.1 bazel 7.0.2