Here's a reproducer:
> $ go mod init example.org/my-project
> go: creating new go.mod: module example.org/my-project
> $ cat >> main.go << "EOF"
> package main
> import _ "example.com/other-module"
> func main() {}
> EOF
> $ go list -mod=readonly ./...
> build example.org/my-project: cannot load example.com/other-module:
> import lookup disabled by -mod=readonly
I think we'd both mis-understood Nicolas's complaint the first time --
it's not that it still tries to access the network with -mod=readonly,
but that even for basic commands for which a read-only mod file/no
network access really *shouldn't* be a problem, it will still just bomb
out.
The go command is "bombing out" here because the code in question
in go.mod provides that package (there are no dependencies in go.mod at all!).
[One of the things go list computes is the dependency graph
(visible if you use go list -json or go list -f '{{.Deps}}').]
It's true that if you have a CI/CD system, then for a successful build
you need to push complete code to it, and that includes a go.mod with
listed dependencies sufficient to cover the relevant imports,
as I described in my original reply to Nicolas. If go.mod were up to date
(for example, if 'go mod tidy' found no work to do) and the local
Go module cache already contained the listed dependencies,
then the 'go list -mod=readonly' command you showed would complete
just fine. You can't push code with an incomplete dependency list to the
CI/CD system and expect it to build, any more than you can push
code with missing function definitions and expect it to build.
Best,
Russ