cd $GOPATH/github.com/clintmod/goBuildBug

^ this is the wrong path, did you mean

cd $GOPATH/src/github.com/clintmod/goBuildBug

@davecheney yep… fixed

yep… fixed

Based on the above reply by the OP. I assume this can now be closed.

can we reopen?
I was correcting the bad path in the steps to repro… the expected behavior is that the build should not fail because there are only test files in the dir.

Sure, I've just assumed based on your answer that it was fixed. Please close it yourself if it all works out.

Duplicate of #8279

I think it's clear that go install github.com/clintmod/goBuildBug/tests should fail with the "no non-test Go files" error. So I think what you are saying is that you expect go install ./... to succeed even if some of the packages named by ./... can not be built. I've updated the issue title accordingly. I don't know whether this is a good idea or not. The current approach is easy to understand.

Just to add my 2c, I've hit this exact issue just now.

My use case is that I'm doing some code generation in a CI build step, and as a last sanity check I try to build a huge repository to make sure that all dependencies (for the generated code too) are correctly vendored in. The simplest way is to do go install ./..., however this fails the CI build step, since there's a folder which only contains tests.

I fully agree that a warning for this scenario is nice. But does it really make sense to fail the entire process for it? I'd expect ./... to build what make sense, and skip what doesn't.

Same here, also in CI for caching deps:

+ CGO_ENABLED=0
+ go install -v -installsuffix static all
github.com/go-playground/form/benchmarks
go build github.com/go-playground/form/benchmarks: no non-test Go files in /go/src/github.com/go-playground/form/benchmarks

@powerman - You are directly trying to install the benchmarks package. That will always fail.

This issue is about trying to install/build a repo with a ./.. and not fail the entire step because an internal folder contains only _test files.

This can be solved with a simple workaround of adding any dummy file with a non _test suffix in the same package. Just have a ignore.go file with a one-liner package tests, and everything works.

In general, our approach towards warnings have been to avoid them in the first place by fixing them. And if it cannot be fixed, throw an error. So, I am not sure whether we should throw a warning. Even if the above workaround is not feasible in some cases, you can always do a go list and install the packages separately.

You are directly trying to install the benchmarks package.

No, I'm not. It's go install all trying to install that package, not me. All I want is to compile and cache all already downloaded packages in a docker image, which will be later used as base image for building my projects in CI - to avoid re-compiling most of my project's dependencies to speedup CI build. Thus I use go install all - is there any better way to do this? ./... doesn't differs much from all in this sense - reason why I use all is to rebuild also stdlib (to get stdlib cached both with and without CGO_ENABLED=0, because some projects supports it and worth using with alpine docker image while others do not).

This can be solved with a simple workaround of adding any dummy file with a non _test suffix

Sure, but it's not my package - it just one of often used dependencies.

Ah that's right. It is all which is doing it. But all applies to all packages under GOPATH. I would guess you know the dependencies needed by your app ? You can just go get those. And use that docker image in your CI. Or am I missing something here ?

Sure, but it's not my package - it just one of often used dependencies.

Yep, I mentioned this above. In that case, you have to install the sub-packages separately.

Maybe @ianlancetaylor has a better solution.

I would guess you know the dependencies needed by your app?

More or less. It's a base image shared between several projects with different dependencies, so it include most common ones.

You can just go get those. And use that docker image in your CI.

I do go get those. And everything is fine, so far.

Or am I missing something here?

Probably this issue happens because after I did go get I wanna rebuild all these packages plus stdlib once again, this time with CGO_ENABLED=0, so I run this: CGO_ENABLED=0 go install -v -installsuffix static all … and it usually fails, for one reason or another, because it tries to install every downloaded package, and not just ones which was installed by go get. So when it fails I run go get -v -t all, then go install again… and repeat that few times until success. 😄

Probably only way to avoid these issues is give up on using all - just run same go get twice, with and without CGO_ENABLED=0, plus also run CGO_ENABLED=0 go install -v -installsuffix static std.

But all of this just means all target is currently mostly useless.

@ianlancetaylor

I think it's clear that go install github.com/clintmod/goBuildBug/tests should fail with the "no non-test Go files" error.

Why is it clear? If there's nothing to do then it should do nothing and exit 0. It's fine to print a warning but why should it exit non-zero?

@clintmod I think it should fail because the command explicitly requests installing a specific package that can not be installed. I don't consider this a case where there is nothing to be done. I consider it a case where the user requested an action that is impossible.

Change https://golang.org/cl/121196 mentions this issue: cmd/go: ignore wildcard-matched test-only packages in go build