When foo is a relative subdirectory, the error message from go build foo/ seems a lot worse when -mod=vendor is set than when it is unset:
example.com$ go version
go version devel +e1a96b82 Wed Apr 29 08:57:33 2020 +0000 linux/amd64
example.com$ go build ./foo
example.com$ go build foo/
package foo is not in GOROOT (/usr/local/google/home/bcmills/sdk/gotip/src/foo)
example.com$ go build -mod=vendor foo/
package foo: cannot find package "." in:
-- foo/foo.go --
-- go.mod --
The error message from the first go build foo/ seems reasonable to me: it clearly indicates that foo was interpreted as a package path, where we expected to find that package, and why we failed to do so.
The error message from go build -mod=vendor foo/ is much worse: it mentions a package ".", which has nothing to do with what the user passed in, fails to mention GOROOT (which is where a package named foo generally ought to be) at all, and buries the vendor part in the middle of the file path.
@nikhita Can confirm, that issue is closely related.
go mod vendor copies into the vendor directory packages needed to build packages in the main module and their tests. Since k8s.io/publishing-bot/cmd/validate-rules is not imported by any package in the main module, it won't be vendored.
This error is shown when vendor mode is enabled and a package that's not present in the vendor directory is needed. In Go 1.14, vendor mode is enabled when vendor/modules.txt is in sync with go.mod and go.mod has go 1.14 or higher.
As a work around, you can import k8s.io/publishing-bot/cmd/validate-rules from a "tools" package that is never built, then run go mod vendor again. It looks like hack/tools/tools.go and build/tools.go are already used to track a few tools like this. You can also use the -mod=mod flag to build without the vendor directory.