When all_proxy set, use git proxy to build xen-tools

[deitch]

Signed-off-by: Avi Deitcher avi@deitcher.net

When all_proxy is set, use a git proxy for building pkg/xen-tools.

Fixes #150

Please test @jren1

cc @rvs

[rvs]

Hey @deitch -- I think this is moving in the right direction, but I'm not a big fan of adding oe-git-proxy since we will be forced to add it to all the containers using git (and that unfortunately includes all the ones relying on go get).

So... two things:

1. I am wondering why git config --global http.proxy XXX is not sufficient ?
2. If it isn't I am wondering if we could explore an option of running a cntlm https://hub.docker.com/r/jaschac/cntlm/ container and then teaching linuxkit to add --link to its invocation of docker build commands.

[deitch]

we will be forced to add it to all the containers using git (and that unfortunately includes all the ones relying on go get

Not really. Only pkg/xen-tools is the problematic one, since it is the only one that insists on using the git:// protocol. Every other one (including all of the ones doing go get) use http protocol. If http_proxy or https_proxy (depending on use case) is set, then go get works fine. And since we now pass http_proxy/https_proxy to docker build, and linuxkit pkg build properly respects it, they all work. This is the troublesome child.

I believe that is why @jren1 put this only in pkg/xen-tools and nowhere else.

I am wondering why git config --global http.proxy XXX is not sufficient ?

Because it only works for http. git:// protocol doesn't work with any of that AFAIK, hence the socks proxy. This really is a unique case.

If it isn't I am wondering if we could explore an option of running a cntlm https://hub.docker.com/r/jaschac/cntlm/ container and then teaching linuxkit to add --link to its invocation of docker build commands.

docker build with another container running isn't officially an option. You sort of can hack it by using docker build --network, but it is messy and not recommended unless you really have no choice. With the ability to just tell it, "use this proxy", this is a much cleaner option.

[deitch]

In the meantime, I need to rebase.

I also don't know why yetus failed. I added the downloaded script to .yetus-excludes. @aw-was-here any idea? Is this that issue from earlier, about having to add to excludes and merge in, and then have a later PR consume it?

[deitch]

Rebased.

[rvs]

Not really. Only pkg/xen-tools is the problematic one, since it is the only one that insists on using the git:// protocol. Every other one (including all of the ones doing go get) use http protocol. If http_proxy or https_proxy (depending on use case) is set, then go get works fine. And since we now pass http_proxy/https_proxy to docker build, and linuxkit pkg build properly respects it, they all work. This is the troublesome child.

Ah! Ok. Then I simply suggest we add GIT_HTTP=y to our Xen build

This is supposed to activate this part and remove the need for oe-git-proxy (as per your explanation): http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=Config.mk;h=0fa4591379911e56049eef5684a2d7f08995b7b3;hb=HEAD#l264

Makes sense @deitch ?

[deitch]

Seriously? They have an http endpoint? I had thought they had insisted on git-protocol only. Ha!

That makes these changes irrelevant. I am going to change this PR to always use HTTP_PROXY for xen-tools and be done.

[deitch]

Just redid it with that simple change.

@jren1 can you please validate?

[eriknordmark]

If this addresses the problem its fine with me.

[deitch]

I will rebase to latest master. @rvs can you approve changes? @jren1 can you confirm it works?

[rvs]

LGTM! But it would be great to get @jren1 sign-off on this.

[deitch]

We just got confirmation from @jren1 by email that we now have full behind-the-proxy support. @rvs please merge in.

[rvs]

Awesome job @deitch ! Thank you!