Go "package ... is not in GOROOT" / "std" - Fix Import Errors in CI

Go tried to resolve an import as a standard-library or GOROOT package and failed. This almost always means the build is not running in module mode - there is no go.mod in scope, or GO111MODULE=off forced legacy GOPATH resolution.

What this error means

A build fails with package github.com/yourorg/app/x is not in std (GOROOT/src/...) or cannot find package ... in GOROOT or GOPATH. Go is looking in the standard library for a third-party or local package.

package github.com/yourorg/app/internal/store is not in
std (/usr/local/go/src/github.com/yourorg/app/internal/store)

Common causes

No go.mod in the build directory

Running go build from a directory with no go.mod (and none above it) drops Go into GOPATH/GOROOT resolution, where your import does not exist.

GO111MODULE=off

Forcing modules off makes Go resolve imports against GOPATH and GOROOT only, so module-style import paths are reported as not in GOROOT.

Building from the wrong working directory in CI

CI ran the build from a parent or unexpected directory, so Go never found the module root.

How to fix it

Run in module mode from the module root

cd "$GITHUB_WORKSPACE"
go env GO111MODULE   # should be on/auto, not off
go build ./...

Enable modules explicitly

export GO111MODULE=on
go build ./...

Confirm the module setup

1. Make sure a go.mod exists at the repo root (go mod init <module-path> if not).
2. Run the build from where go.mod lives, or from a subdirectory under it.
3. Check go env GOMOD points at your go.mod, not /dev/null.

How to prevent it

• Always build from the module root in CI.
• Leave GO111MODULE at its default (module mode) unless you have a specific reason.
• Keep a go.mod at the repository root.

Related guides