CODEWITHSUNDEEP
go
stackoverflower
stackoverflower

Reputation: 4073

go test fails with "can't load package build constraints exclude all Go files"

When I run this command

go test -tags integration $(go list ./... | grep -v /vendor/)

go fails with this for some packages that has all tests marked with // +build !integration

can't load package: build constraints exclude all Go files

Is there a way I can make go test ignore those packages in this case, instead of failing? Thanks

Upvotes: 13

Views: 19274

Answers (4)

Thomas Kilkelly
Thomas Kilkelly

Reputation: 125

Following on from snowfox's answer, if you can't remove the directive (becuase it was likely put there for a reason), you can still run the test by using the tag that was applied to that file (more info here).

If your file start looks like this:

//go:build bar
package foo

Then you can run the test by running go test ./foo_test.go --tags=bar

Upvotes: 1

snowfox
snowfox

Reputation: 2098

The package you are importing might contain some source files with a conditional complication flag, which is a directive you may find at the top of the files like:

//+build linux darwin windows
package main

import "fmt"

func main() {
    fmt.Println("hello")
}

The +build directive followed by one or multiple platforms indicates where this source code is supposed to be compiled on.

Therefore, you can simply try removing this directive to resolve the failure. It worked for me.

Upvotes: 1

bharat nc
bharat nc

Reputation: 127

For whatever it's worth : I was seeing similar errors while building my code. In my case, my main file had // +build go1.13 at the top of it and I was trying to get the file built using go1.12.x. Removing +build go1.13 fixed the issue.

Upvotes: 1

Mr_Pink
Mr_Pink

Reputation: 109464

You will only get that error if all the files in the package are excluded by your build constraints, not just the test files. If that's what you want, just add a single package file with no code and the package will still be able to be loaded. For example, many packages put their package level docs in a separate file, which you could use to always have a valid package:

// Package foo does foo
package foo

Upvotes: 15

Related Questions