operator-sdk build fails on latest master with 'make images-dev'

[dmvolod]

Strange operator-sdk build behavior after some latest updates

operator-sdk build docker.io/apache/camel-k:1.0.0-M1-SNAPSHOT
build github.com/apache/camel-k/cmd/manager: cannot load github.com/knative/serving/pkg/apis/serving/v1beta1: open /home/dvolodin/go/src/github.com/apache/camel-k/vendor/github.com/knative/serving/pkg/apis/serving/v1beta1: no such file or directory
Error: failed to build operator binary: (failed to exec []string{"go", "build", "-o", "/home/dvolodin/go/src/github.com/apache/camel-k/build/_output/bin/camel-k", "-gcflags", "all=-trimpath=/home/dvolodin/go/src/github.com/apache", "-asmflags", "all=-trimpath=/home/dvolodin/go/src/github.com/apache", "-mod=vendor", "github.com/apache/camel-k/cmd/manager"}: exit status 1)

[astefanutti]

It may be due to -mod=vendor, while the build uses Go modules.

[astefanutti]

You may need to upgrade your Operator SDK binary to latest 0.9.0 version.

[dmvolod]

@astefanutti i'm on the latest version
[dvolodin@dvolodin camel-k]$ operator-sdk version
operator-sdk version: v0.9.0, commit: 560208dc998de497bbf59fea1b63426aec430934

[astefanutti]

You need to invoke the Go commands with the environment variable GO111MODULE=on, in case you've checked out the repository inside of the $GOPATH/src tree.

[dmvolod]

@astefanutti , I'm using GO111MODULE env variable. It's strange that all were working 2 days ago.

[astefanutti]

I'm running out of ideas 😉 but that -mod=vendor looks suspicious to me.

[dmvolod]

@astefanutti do we need to place code inside $GOPATH/src
when i place it outside, the following error is occurs
operator-sdk build docker.io/apache/camel-k:1.0.0-M1-SNAPSHOT
FATA[0000] dependency manager "dep" requires working directory to be in $GOPATH/src

Before removing line 'go mod vendor' from make all was working fine.

[lburgazzoli]

mh, go mod vendor should have been removed long ago

[dmvolod]

@lburgazzoli it just removed 2 days ago by this commit
2fb5fc5

[lburgazzoli]

ah that one yes

[dmvolod]

@lburgazzoli after this fix this issue occurs on my laptop.
Do you have suggestions related to it?

[astefanutti]

@dmvolod it seems Go modules is deactivated somehow in your environment, and it still uses Dep, which requires the vendor directory.

Could you double check you environment variables and your Go version?

Do you have any GOFLAGS=-mod=vendor?

[dmvolod]

@astefanutti , just GOPATH and GO111MODULE
[dvolodin@dvolodin camel-k]$ export | grep GO
declare -x GO111MODULE="on"
declare -x GOPATH="/home/dvolodin/go"

[astefanutti]

@dmvolod, what about go version?

I would try export GO111MODULE="on" instead of declare -x GO111MODULE="on" just in case 😄.

Anyhow, Go does not activate modules, hence your error, which is likely environment related.

[dmvolod]

I tried different versions and after five into operator-sdk code, detects that it's looking for the gopkg.toml file first. I deleted it and all becoming build fine.
@astefanutti, @lburgazzoli can we safely remove dep required files from repo?

[astefanutti]

The only reason I know we've decided to keep the Dep files around is for the Knative eventing dependency on Camel K until it migrates to Go modules too: https://github.com/knative/eventing-contrib/blob/5ce18048c08b19437ac72fbdfeb4bf4a8d17c862/Gopkg.toml#L105.

It's weird it does not seems to reproduce on CI or locally for me 🤔. So there may be another way to work around this.

[dmvolod]

Ok, will look into another workaround.
Maybe it's an OS/fedora regression.

[dmvolod]

@astefanutti
CI file still contains 'go mod vendor' command. Looks like this is a reason why CI is not failing.
I'm diving into operator-sdk code and the logic to detect of dependency manager is very simple and dep has priority.
https://github.com/operator-framework/operator-sdk/blob/d6e1aba9fa512ff9d441b648f548399c86929643/internal/util/projutil/project_util.go#L87-L104

May be I can't see very simple things.

[lburgazzoli]

So I have the same issue and the CI does not fail because it does not use the operator-sdk but plain docker :) so I would suggest to apply the same logic in the makefile. Another hacky way could be to run the operator from a different location so it does not find Gopkg.lock.

@astefanutti @nicolaferraro what do you think ?

We should also report the issue upstream

[astefanutti]

@dmvolod damn it seems my brain is throttling beyond 40ºC here, so I missed that go mod vendor in Travis config.

[astefanutti]

@lburgazzoli I've created #872 (remove Dep files) which hopefully should make operator-sdk less confused about the history of Go dependencies management 😄.

[lburgazzoli]

but it does not make any difference as operator-sdk is not used by the travis build :)

[lburgazzoli]

Btw, I've created #871 to avoid go mod vendor

[dmvolod]

@lburgazzoli , @astefanutti thanks.
I will report the issue and discuss it in operator-sdk upstream.

[astefanutti]

Let me close this as it should be fixed with #872. Feel free to re-open if that is not the case.

[astefanutti]

@dmvolod thanks a lot for your valuable inputs on this. Let us know the outcome of the discussion upstream.

[aldettinger]

make images-dev still produce the same error in my environment with operator-sdk v0.9.0, GO111MODULE=on and git up-to-date at commit 71557bd.

@dmvolod I'm considering reopening this issue. Could you please confirm that recent commits fixes make images-dev on your machine please ?

[dmvolod]

@aldettinger, I'm fine with build right now.
Please pull latest master from upstream.

[aldettinger]

It may be another issue then, I'll investigate that. Many thanks @dmvolod .

[dmvolod]

operator-framework/operator-sdk#1738