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

Please add support for GOPROXY build-arg #315

Closed
anguslees opened this issue Jan 6, 2020 · 9 comments
Closed

Please add support for GOPROXY build-arg #315

anguslees opened this issue Jan 6, 2020 · 9 comments
Labels
Request Request for image modification or feature

Comments

@anguslees
Copy link

GOPROXY is very much like http_proxy and is expected to be used/set by the build environment, not by the source project. Please add ARG GOPROXY to the standard golang Dockerfiles >= 1.13, so this value may be provided externally during docker-based golang builds.

Note that there are actually several relevant environment variables, so we may as well support all of them at the same time. I think the build-args we should add are: GOPROXY, GONOPROXY, GOPRIVATE, GOSUMDB, GONOSUMDB.

Note also that I'm not suggesting we change any upstream defaults, only that we provide the ability to configure these values when appropriate (unlike #303, for example).

(I think this is technically a trivial/obvious edit, but let me know if it would be easier if I provided a concrete PR.)

@wglambert wglambert added the Request Request for image modification or feature label Jan 6, 2020
@tianon
Copy link
Member

tianon commented Jan 9, 2020

I'm not sure I understand what you're asking for -- what concrete change are you suggesting we make?

As-is, I don't believe there's anything preventing you from using -e on docker run, ENV or ARG in a Dockerfile, etc to set these variables however you wish in your own builds/environments, nor do I see anything concrete we could add to make it "easier" or more possible than it already is. 😕

@JulienBreux
Copy link

JulienBreux commented Jan 9, 2020

Hi! 👋

You just can use docker run -e GOPROXY=https://proxy.inodes.org golang ?

Or:

FROM golang

ENV GOPROXY=https://proxy.inodes.org

In your Dockerfile?

@tianon
Copy link
Member

tianon commented Jan 9, 2020 via email

@anguslees
Copy link
Author

anguslees commented Jan 12, 2020

I want docker build --build-arg=GOPROXY ... to work (and the other vars mentioned above). I believe (from a quick experiment and scan of docs) that this requires ARG GOPROXY in the Dockerfile - you can't just make up a build-arg on the command line (like you can with env).

In particular, build-args do not get captured in the resulting layers, which is appropriate for GOPROXY, and do not affect the resulting container - they're purely a build-time parameter. Conversely, there is no docker build -e because ENV variables (which do affect the resulting layers) should be captured in Dockerfiles and not injected by the builder.

I consume (rebuild locally) many golang-based upstream projects that are built FROM the standard golang library images. It would be a shame for me (and anyone else that needs to not use the default proxy for some reason) to have to patch every one of those downstream Dockerfiles to add ARG GOPROXY, when we could just push that up into the golang image itself.

@tianon
Copy link
Member

tianon commented Jan 14, 2020

Right, but if that's something you want for builds of your image, the ARG needs to be defined in your Dockerfile -- us adding them to this repository's Dockerfile won't actually do anything.

@tianon
Copy link
Member

tianon commented Jan 14, 2020

To put that another way, if we add ARG GOPROXY to our Dockerfile, that metadata will only affect the following lines in the Dockerfile here, and will not be preserved as an available ARG in the final image which others consume.

@anguslees
Copy link
Author

anguslees commented Feb 3, 2020

Oh you're right - build-args aren't perserved/inherited (that's kind of the point). Sorry, I should have verified that first :/

Closing this unimplementable feature request.

@anguslees
Copy link
Author

anguslees commented Feb 3, 2020

Aha, reopening. I needed to use ONBUILD, since (as you point out) I need the directive to take affect as part of the "child" docker build.

Please add the following to the golang dockerfile:

ONBUILD ARG GOPROXY
ONBUILD ARG GONOPROXY
ONBUILD ARG GOPRIVATE
ONBUILD ARG GOSUMDB
ONBUILD ARG GONOSUMDB

@anguslees anguslees reopened this Feb 3, 2020
@yosifkit
Copy link
Member

yosifkit commented Apr 9, 2020

While ARG doesn't fit some of the arguments we've used in the past when dropping ONBUILD images (docker-library/official-images#2076), we still rather not add any ONBUILD instructions to official-images.


I don't want to introduce unexpected "magic" that will skew users expectations for how Docker images work. Without being able to control if and when they trigger, ONBUILD instructions are a mistake and should instead just be regular instructions in the user's Dockerfile.

Assuming they were added to golang, then this contrived dockerfile would have to redo the apt layer when the user has to change one of the build-args that really only affects the go build line

FROM golang
# ONBUILD's trigger here

RUN set -ex; \
	apt-get update; \
	apt-get install -y some-build-deps; \
	rm -rf /var/lib/apt/lists/*

COPY my-go-code /where/i/want/it/
RUN go build .......

@yosifkit yosifkit closed this as completed Apr 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Request for image modification or feature
Projects
None yet
Development

No branches or pull requests

5 participants