link: add stamped VCS build info - #4695
Open
sluongng wants to merge 1 commit into
Open
Conversation
sluongng
force-pushed
the
sluongng/vcs-buildinfo-stamping
branch
from
August 21, 2026 12:57
51afe0b to
5b3e00a
Compare
fmeum
pushed a commit
that referenced
this pull request
Aug 21, 2026
**What type of PR is this?** Feature **What does this PR do? Why is it needed?** rules_go records dependency modules in `BuildInfo.Deps`, but leaves `BuildInfo.Main` empty even when package metadata identifies the module that owns an executable. Build-info consumers therefore cannot report the main module path and version. This change passes two distinct values to the linker: - The executable package's import path populates `BuildInfo.Path`. - The Go PURL in its package metadata populates `BuildInfo.Main`. Package metadata is kept unconditionally on `GoInfo` and archive data. At link time, the target metadata is selected as the main module and that module path is filtered from the candidate dependencies. This prevents a `go_test` binary from reporting its own module in `BuildInfo.Deps` without a test-only suppression flag or a duplicate provider field. The new `go.binary` and `go.link` parameters are appended to preserve positional compatibility for custom Starlark rules. Tests cover ordinary binaries, embedded main packages, test binaries, binaries without metadata, and direct `go.archive` to `go.link` callers. **Which issue(s) does this PR fix?** No linked issue. **Other notes for review** Build-info stack: 1. #4694 — add main-module build info (this PR) 2. #4695 — add stamped VCS build info The second draft is cumulative against `master` because both heads are fork-owned. It depends on this PR and is rebased after this PR changes. Validation: - `bazel --nohome_rc test //tests/...` — 467 passed, 1 Darwin-only test skipped - `bazel test //go/tools/builders:all //tests/core/go_binary:buildinfo_test //tests/core/starlark:package_metadata_test //tests:buildifier_test` - `bazel build //docs/...` - `bazel test //docs/...` - `git diff --check`
sluongng
force-pushed
the
sluongng/vcs-buildinfo-stamping
branch
12 times, most recently
from
August 27, 2026 21:36
e6be626 to
5f18f10
Compare
Stamped rules_go binaries cannot report their source revision or dirty
state through runtime/debug or go version -m. Users therefore cannot
apply the same provenance checks available for binaries built by cmd/go.
This matters because release verification depends on that provenance.
Map STABLE_VCS, STABLE_VCS_REVISION, STABLE_VCS_TIME, and
STABLE_VCS_MODIFIED workspace values to Go's vcs.* build settings. These
names follow Bazel's stable-status convention while mirroring Go's
build information keys, including the true or false value used by
vcs.modified. Normalize timestamps to UTC.
Own one filtered status action on each configured go_context_data
target and let eligible executable links consume its shared output. The
action graph is:
```text
stable-status.txt
│
▼
one GoVCSStamp action
owned by configured //:go_context_data
│
▼
go_context_data.vcsstamp
│
├── eligible GoLink for binary A
├── eligible GoLink for binary B
└── eligible GoLink for test C
```
This avoids declaring the same filter action for every binary while
keeping the raw stable-status file out of GoLink inputs, so unrelated
status changes do not relink binaries.
Emit VCS settings only when the target and the package metadata
selected for BuildInfo.Main both come from the main repository. Carry
the selected metadata file through embeds and tests, then infer
its provenance from File.owner at the link boundary. Infer target
provenance from the active Go context and treat unknown metadata
owners as untrusted.
Embedding the current revision in each eligible stamped go_test binary
changes that executable whenever HEAD changes. Creating a commit,
amending a commit message, or rebasing therefore invalidates cached
test results even when the test source did not change. Compilation
outputs remain reusable. Document this cost and recommend keeping
VCS stamping disabled for routine development while enabling it for
release or provenance-verification builds.
Cover shared action inputs, stable refreshes, go_binary and go_test,
direct links, external provenance, and non-executable link modes.
sluongng
force-pushed
the
sluongng/vcs-buildinfo-stamping
branch
from
August 28, 2026 08:04
5f18f10 to
13d314e
Compare
sluongng
marked this pull request as ready for review
August 28, 2026 08:17
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stamped rules_go binaries cannot report their source revision or dirty
state through runtime/debug or go version -m. Users therefore cannot
apply the same provenance checks available for binaries built by cmd/go.
This matters because release verification depends on that provenance.
Map STABLE_VCS, STABLE_VCS_REVISION, STABLE_VCS_TIME, and
STABLE_VCS_MODIFIED workspace values to Go's vcs.* build settings. These
names follow Bazel's stable-status convention while mirroring Go's
build information keys, including the true or false value used by
vcs.modified. Normalize timestamps to UTC.
Own one filtered status action on each configured go_context_data
target and let eligible executable links consume its shared output. The
action graph is:
This avoids declaring the same filter action for every binary while
keeping the raw stable-status file out of GoLink inputs, so unrelated
status changes do not relink binaries.
Emit VCS settings only when the target and the package metadata
selected for BuildInfo.Main both come from the main repository. Carry
the selected metadata file through embeds and tests, then infer
its provenance from File.owner at the link boundary. Infer target
provenance from the active Go context and treat unknown metadata
owners as untrusted.
Embedding the current revision in each eligible stamped go_test binary
changes that executable whenever HEAD changes. Creating a commit,
amending a commit message, or rebasing therefore invalidates cached
test results even when the test source did not change. Compilation
outputs remain reusable. Document this cost and recommend keeping
VCS stamping disabled for routine development while enabling it for
release or provenance-verification builds.
Cover shared action inputs, stable refreshes, go_binary and go_test,
direct links, external provenance, and non-executable link modes.
Future work
External binaries are intentionally out of scope for this change. A binary from a version-pinned
go_repositorycontinues to report its module version throughBuildInfo.Main.Version, but this PR does not emitvcs.*settings for external-repository targets. A future change could add repository-specific VCS metadata for commit-pinned external repositories; it must come from that external repository rather than the main workspace's status file.