Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a vendor directory to avoid downloading all go modules when execute "go build" #816

Closed
Mingli-Yu opened this issue Mar 1, 2021 · 10 comments

Comments

@Mingli-Yu
Copy link

Mingli-Yu commented Mar 1, 2021

After fetch the cni code via "git clone git://github.com/containernetworking/cni.git" and then continue to build the code via "go build", but it still try to fetch the dependencies defined in ../cni/go.module after a7cceb9 included in go 1.15. It's better to provide a vendor directory to avoid downloading all go modules when execute "go build".
go version: 1.15
cni version: v0.8.0

@antoninbas
Copy link

I'm no expert but projects that use Go modules typically no longer include a vendor directory. So I'm not sure it is "better to provide a vendor directory". See the "End of Vendoring" in https://research.swtch.com/vgo-module. The community seems to be transitioning to self-hosted or public proxies such as https://github.com/gomods/athens to ensure availability of dependencies or enable "offline" builds. You may also build your own vendor directory, with the caveat that vendor diectories are ignored by go build by default unless you provide -mod vendor.

@Mingli-Yu
Copy link
Author

Mingli-Yu commented Mar 5, 2021

@antoninbas, thanks your response, yes, I just want to enable offline build.

@bboreham
Copy link
Contributor

bboreham commented Mar 6, 2021

Please explain what you built using go build. This repo is primarily a library.

@Mingli-Yu
Copy link
Author

@bboreham
Yes, I indeed know the cni is a library and there is another package depends on cni in my build environment, so I need to run build against cni and want to do a offline build in my env. Thanks!

@bboreham
Copy link
Contributor

bboreham commented Mar 8, 2021

Ok so the vendor directory would be in your project not in ours.

@bboreham bboreham closed this as completed Mar 8, 2021
@Mingli-Yu
Copy link
Author

@bboreham,
Thanks your response, but I don't understand what you mean. Initially I open the issue is because I clone the cni code via "git clone git://github.com/containernetworking/cni.git" and then continue to run "go build", but don't want it connect the network to fetch the dependencies defined in go.mod file for cni during "go build" phase, is there any means? Thanks in advance!

@bboreham
Copy link
Contributor

bboreham commented Mar 9, 2021

I clone the cni code via "git clone git://github.com/containernetworking/cni.git" and then continue to run "go build"

If I do this it says "no Go files in /home/vagrant/src/github.com/containernetworking/cni".

What you indicated before is that you are building your own project, which will say something like import "github.com/containernetworking/cni/pkg/types/current". And you can have a vendor directory in that project.

As described at https://golang.org/ref/mod#vendoring, "the go command ignores vendor directories in locations other than the main module's root directory", so even if we did what you asked it would not change anything. The "main module" is whatever you are building; the CNI library is not your main module.

@Mingli-Yu
Copy link
Author

Mingli-Yu commented Mar 11, 2021

@bboreham,
1, mkdir -p $GOPATH/src/github.com/containernetworking
2, cd $GOPATH/src/github.com/containernetworking
3, git clone git://github.com/containernetworking/cni.git
4, cd cni/libcni
5, go build

@bboreham
Copy link
Contributor

This is not something you need to do, or should do.
Just import the package(s) and build your project in its directory; Go will compile all dependencies.

@Mingli-Yu
Copy link
Author

Mingli-Yu commented Mar 16, 2021

@bboreham,
Thanks very much for your response!
Actually I don't quite understand what you mean when you say "This is not something you need to do, or should do."

In my env, it's easy to reproduce that it needs to connect the network during "go build" stage with below steps. And all I want just provide a method not let it connect the network during "go build" stage. Thanks a lot!
1, mkdir -p $GOPATH/src/github.com/containernetworking
2, cd $GOPATH/src/github.com/containernetworking
3, git clone git://github.com/containernetworking/cni.git
4, cd cni/libcni
5, go build

mccv1r0 added a commit to mccv1r0/cni that referenced this issue Jan 30, 2023
One rule for the life of CNI vs one for ipMasq, portmap etc.

This is an alternative to adding an unique container IP specific rules
every cniADD for ipMasq, portmap and then removing when cniDel is called.

Fixes containernetworking#816

Signed-off-by: Michael Cambria <mcambria@redhat.com>
mccv1r0 added a commit to mccv1r0/cni that referenced this issue Jan 30, 2023
One rule for the life of CNI vs one for ipMasq, portmap etc.

This is an alternative to adding an unique container IP specific rules
every cniADD for ipMasq, portmap and then removing when cniDel is called.

Fixes plugins containernetworking#816

gofumpt

Signed-off-by: Michael Cambria <mcambria@redhat.com>
mccv1r0 added a commit to mccv1r0/cni that referenced this issue Jan 30, 2023
One rule for the life of CNI vs one for ipMasq, portmap etc.

This is an alternative to adding an unique container IP specific rules
every cniADD for ipMasq, portmap and then removing when cniDel is called.

Fixes plugins containernetworking#816

gofumpt

Signed-off-by: Michael Cambria <mcambria@redhat.com>
mccv1r0 added a commit to mccv1r0/cni that referenced this issue Feb 8, 2023
One rule for the life of CNI vs one for ipMasq, portmap etc.

This is an alternative to adding an unique container IP specific rules
every cniADD for ipMasq, portmap and then removing when cniDel is called.

Fixes plugins containernetworking#816

gofumpt
Keep lint happy?

Signed-off-by: Michael Cambria <mcambria@redhat.com>
mccv1r0 added a commit to mccv1r0/cni that referenced this issue Feb 8, 2023
    One rule for the life of CNI vs one for ipMasq, portmap etc.

    This is an alternative to adding an unique container IP specific rules
    every cniADD for ipMasq, portmap and then removing when cniDel is called.

    Fixes plugins containernetworking#816

    gofumpt
    Keep lint happy?

Signed-off-by: Michael Cambria <mcambria@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants