go list -json: Query Packages and Modules in CI
go list prints information about packages and modules; -json emits structured records and -m switches it to module mode for dependency queries.
When CI needs the package list, import deps, or the module graph, go list is the canonical source. It is what tooling parses instead of guessing from the file tree.
What it does
go list resolves the named packages and reports fields like ImportPath, Dir, GoFiles, and Imports. -json outputs full records; -deps includes transitive dependencies; -m lists modules (the build list) instead of packages; -f applies a Go text/template for custom output.
Common usage
go list ./...
go list -m all # full module build list
go list -json -deps ./... > packages.json
go list -f '{{.ImportPath}} {{.Stale}}' ./...Flags
| Flag | What it does |
|---|---|
| -json | Emit structured JSON records |
| -m | Module mode: list modules, not packages |
| -m -u | Show available upgrades for modules |
| -deps | Include all dependencies of the named packages |
| -f <template> | Format output with a Go text/template |
| -find | Skip resolving imports (faster listing) |
In CI
Use go list -m all to snapshot the dependency build list for audits, or go list -json -deps ./... to feed a tool. With GOFLAGS=-mod=readonly, list will not edit go.mod; if go.sum is incomplete it errors instead, which is what you want in CI. Cache the module cache so list runs offline after a download step.
Common errors in CI
"no required module provides package ...; to add it: go get ..." means an import has no matching require. "package ... is not in std" or "is not in GOROOT" means a wrong import path. "go: updates to go.mod needed, disabled by -mod=readonly" means list wanted to edit go.mod; run go mod tidy first. "build constraints exclude all Go files" surfaces here too when -tags excludes everything.