build: cannot build in a user fork repo

[grahamwhaley]

I can build vc in its master checked out repo, but not in my user fork repo:

$~/gopath/src/github.com/grahamwhaley/containers/virtcontainers$ make
     GOBUILD  build
# github.com/grahamwhaley/containers/virtcontainers
./cni.go:87: cannot use result (type "github.com/containers/virtcontainers/vendor/github.com/containernetworking/cni/pkg/types".Result) as type "github.com/grahamwhaley/containers/virtcontainers/vendor/github.com/containernetworking/cni/pkg/types".Result in argument to convertCNIResult:
        "github.com/containers/virtcontainers/vendor/github.com/containernetworking/cni/pkg/types".Result does not implement "github.com/grahamwhaley/containers/virtcontainers/vendor/github.com/containernetworking/cni/pkg/types".Result (wrong type for GetAsVersion method)
                have GetAsVersion(string) ("github.com/containers/virtcontainers/vendor/github.com/containernetworking/cni/pkg/types".Result, error)
                want GetAsVersion(string) ("github.com/grahamwhaley/containers/virtcontainers/vendor/github.com/containernetworking/cni/pkg/types".Result, error)
Makefile:29: recipe for target 'build' failed
make: *** [build] Error 2

I believe this is a known issue - if somebody could add to this ticket any details of exactly what the problem with the CNI types are and why/how they are tied to the repo path, and any suggestions on how we effectively fix this - much appreciated.

[grahamwhaley]

OK, maybe now I understand the core issue, and a potential workaround.

Fundamentally, it is tied to golang packages, import paths and forks on github. We can see here: https://github.com/containers/virtcontainers/blob/master/cni.go#L25

that we directly import one of our own subdir packages:

cniPlugin "github.com/containers/virtcontainers/pkg/cni"

and, of course when you fork and do a normal go get or git clone from github if your fork, then the path where you are now building does not match that import path - and, hence the 'type clash' build failure.

One fix to get stuff to build is to rewrite all the imports to point at your new path (maybe using something like https://godoc.org/golang.org/x/tools/cmd/gomvpkg, or a script as found in the thread at https://stackoverflow.com/questions/14323872/using-forked-package-import-in-go), but that would then make a complete mess of your git diff and trying to commit patches. A better solution (also on that stackoverflow page), is probably:

• clone and work in the original source repo
• but add a remote to point at your forked user repo
• and then push branches/changes to that user remote for raising PRs on github.

Anybody want to confirm this, and ack that adding a remote repo is the best workflow method? If so, I'll add it to the developer docs.

I will also likely add info on how to pin the vendoring in cc-runtime dep files so you can test virtcontainers changes with cc-runtime, unless somebody speaks up.

[sboeuf]

@grahamwhaley I think this is the way to go. I don't use this for virtcontainers since I push directly onto the main repo (I know it's wrong...), but I do that for Kata Containers and it works great. The Kata agent cannot build if you call into make from your forked repo, so I develop on the main one, and I push to a new branch on my forked one.

Adding this to the doc is the best thing to do since I am not sure there is something simpler we can do about it (as you've detailed it).

[amshinde]

@grahamwhaley Adding a remote repo is the best workflow method. I usually clone the master/upstream repo and then continue with 2 remotes "upstream" (to point to the upstream repo) and "origin"(to point to my forked repo).

[grahamwhaley]

Right. My 'normal' workflow is to have those same two remotes, but to work in my forked repo :-) For vc, we need to flip that over. I'll PR a doc update.