Support for pre.Dockerfile.* #3999
Conversation
|
Download the artifacts for this pull request: |
|
Oh, there is a very specific reason for the explicit proxy support - docker-compose doesn't actually put the HTTP_PROXY into the build stage at this point, meaning that you can't build images or add to images that require proxying without detecting the HTTP_PROXY as was done in that code. It's unfortunate but true. We have to figure out how to get HTTP_PROXY into the build stage. |
I don't think this is correct. First, the only thing your code seems to be doing is checking for the presence of the env var and if so, making it available on the Dockerfile through |
|
Fixed the md error. |
|
Hmm, it still didn't pass the docs check but EDIT: I saw the error, a link not working but it must have been a glitch because the one reported is definitely up and valid. |
|
Don't worry about that docs check. Sometimes random sites start blocking various kinds of access, we'll sort it out. Obviously not the fault of this PR. |
| @@ -879,21 +879,6 @@ func WriteBuildDockerfile(fullpath string, userDockerfilePath string, extraPacka | |||
| ARG BASE_IMAGE | |||
| FROM $BASE_IMAGE | |||
| ` | |||
| // Provide proxy handling inside container if necessary | |||
There was a problem hiding this comment.
Sorry to say I jumped the gun about being able to remove this. Not sure if there's been a change in docker-compose v2 or what, but docker-compose v2 does not respect HTTP_PROXY (or pass it in) at build time, meaning that if we don't inject this into the Dockerfile it doesn't get there. It does get there without this for docker run but not for docker-compose build, meaning that behind a proxy adding extra debian packages doesn't work without something like this approach. I can't say when this changed, but I was unable to get webimage_extra_packages to work (ever) without injecting the HTTP_PROXY into the build instructions as here.
There was a problem hiding this comment.
But how did the OP on #3960 made it work before on v1.19.2? I am missing something in regards of env vars.
I gave something a try with my local build:
a pre.Dockerfile.proxy with:
ARG HTTP_PROXY
# The below env file can be removed if you don't want it to also be an env var. I would probably add it though.
ENV HTTP_PROXY=$HTTP_PROXY
RUN echo $HTTP_PROXY > /tmp/proxy
And a
docker-compose.proxy.yml with:
version: '3.6'
services:
web:
build:
args:
- HTTP_PROXY=${HTTP_PROXY}
worked for me, I had the content of my manually set environment var HTTP_PROXY in /tmp/proxy on the container as well as an env var set.
|
Yes, your approach with an arg would work as well, should be the same thing. And I guess a ddev-get add-on that added something to the web-image build args would solve it. So yes, that's got potential. I'll have to test it. |
|
Works with https://github.com/rfay/ddev-proxy-support - would love anybody else to try that out. You need the artifacts from #3999 (comment) (or build this PR) and then |
|
Rebased and added capabilities marker in |
Partially reverts
with a
pre.Dockerfile.*approach and keeping regularDockerfile*at the end of the insertions.From Discord: https://discord.com/channels/664580571770388500/997163304822771842
Release Consequences