Repository navigation
Build go-licenses with the same toolchain as the main module - #1003
tiffanny29631 wants to merge 1 commit into
Conversation
kubernetes-prow
Bot
added
kind/bug
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: tiffanny29631 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
kubernetes-prow
Bot
added
the
size/S
tiffanny29631
changed the title
| - name: Check licenses | ||
| working-directory: git-sync | ||
| run: | | ||
| make licenses |
There was a problem hiding this comment.
This doesn't verify licenses, this generates licenses
What is the intent of the change?
There was a problem hiding this comment.
The target is removed and change is reworked.
There was a problem hiding this comment.
CI already uses a Go new enough for both modules it couldn't catch this anyway. I dropped the CI step and the tools/go.mod change. The PR is now just the Makefile fix.
Can you explain more? It doesn't fail for me. |
go-licenses decides whether a package is part of the standard library by
comparing its directory against the GOROOT it was compiled with. The
Makefile builds go-licenses from the tools/ module but runs it against the
main module, and with GOTOOLCHAIN=auto those can resolve to different
toolchains (tools/go.mod has `toolchain go1.24.1`, go.mod has `go 1.25.0`).
When that happens every stdlib package is reported as "does not have module
info" and `make container` fails.
This does not show up in CI because CI pins a Go version that satisfies
both modules, but it reproduces with any host Go older than the main
module's `go` line:
docker run --rm -e GOTOOLCHAIN=auto -v "$PWD":/src -w /src \
golang:1.23.0 make .licenses
Pin GOTOOLCHAIN for the tools build to the version the main module
resolves to, so both steps use the same GOROOT.
16b756c to
a937d1e
Compare
kubernetes-prow
Bot
added
size/XS
Sorry, the original description was thin, and the original change didn't actually fix the root cause. I've reworked the PR. It fails when the host Go is older than the main module's go line and GOTOOLCHAIN=auto (the default for tarball installs; our CI image has Go 1.23.0). tools/ then builds go-licenses with one toolchain and go list ./... runs with another, and go-licenses misclassifies every stdlib package because it compares against its compiled-in GOROOT. Repro: docker run --rm -e GOTOOLCHAIN=auto -v "$PWD":/src -w /src golang:1.23.0 make .licenses CI doesn't hit it because it pins Go 1.25.x. The fix is one line: build go-licenses with whatever toolchain the main module resolves to. |
tiffanny29631
changed the title
3 participants
/kind bug
go-licenses decides whether a package is stdlib by comparing it against the GOROOT it was compiled with (isStdLib). The Makefile builds go-licenses from
tools/but runs it on the main module, and withGOTOOLCHAIN=autothose can resolve to different toolchains (tools/go.modhastoolchain go1.24.1,go.modhasgo 1.25.0). When they differ, every stdlib package fails with "does not have module info" andmake containerfails.CI doesn't hit this because it pins Go 1.25.x. Any host Go older than the main module's
goline reproduces it:docker run --rm -e GOTOOLCHAIN=auto -v "$PWD":/src -w /src golang:1.23.0 make .licenses
E... library.go:159] Package net/url does not have module info. Non go modules projects are no longer supported...
F... main.go:75] some errors occurred when loading direct and transitive dependency packages
This pins
GOTOOLCHAINfor the tools build to the version the main module resolves to (go env GOVERSIONin the repo root), so both steps use the same GOROOT. Tested with golang:1.23.0, 1.24, and 1.25 (GOTOOLCHAIN=autoandlocal).Dropped the earlier
toolchainremoval (it didn't fix the mismatch) and the CI step (per review).