diff options
| author | Ian Alexander <jitsu@google.com> | 2026-02-24 12:00:40 -0500 |
|---|---|---|
| committer | Michael Matloob <matloob@golang.org> | 2026-03-16 11:44:50 -0700 |
| commit | a8a5b81473c00e857dd9963dc027dc1c10016d79 (patch) | |
| tree | 12789d4eb948ceed20fc11331e160aa53b842004 /test/codegen | |
| parent | 655aa335c951c3b1a61560016ad2cd2f6eac1684 (diff) | |
| download | go-a8a5b81473c00e857dd9963dc027dc1c10016d79.tar.xz | |
cmd/go: ensure go.mod and go.sum are consistent after `go get -tool`
The issue was that `go get -tool` could trigger module upgrades (due to
the tool's own requirements) that were not correctly captured by the
final consistency check in `checkPackageProblems`. This happened because
`updateTools` was being called after `checkPackageProblems`, and even if
moved earlier, it failed to update the resolver's internal build list
representation. This left some incidentally upgraded modules (like
github.com/go-logr/logr in the gonzo module) without their corresponding
zip sums in go.sum, causing subsequent builds to fail.
The fix involves:
1. Moving the updateTools call before checkPackageProblems in runGet.
2. Ensuring the resolver's buildList and buildListVersion are
explicitly refreshed from the updated module graph after updateTools is
called.
This ensures that checkPackageProblems correctly identifies all modules
that were upgraded during the `go get -tool` operation and fetches the
necessary checksums, maintaining module consistency.
A test and associated necessary vcs-test configuration are added to
prevent regressions in the future.
Fixes #74691.
Change-Id: I1a7e22a35132bcbee2ceac1ff7fc190666db965b
Reviewed-on: https://go-review.googlesource.com/c/go/+/738660
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Diffstat (limited to 'test/codegen')
0 files changed, 0 insertions, 0 deletions
