Act should pass proxy build args when building Docker actions
Act version
act version 0.2.76
Feature description
Act does not pass any build args to Docker when it builds Docker-based actions. As a result, if Act is run in an enterprise environment where access to the internet is through a proxy, then these actions all break and are unusable, i.e. all third-party docker actions are unusable.
Act should allow the user to optionally pass in proxy variables (HTTP_PROXY, HTTPS_PROXY and NO_PROXY) to the build of Docker actions. This should also include the lowercased versions too.
PR submitted, where --pass-proxy-vars-to-docker-build will pass the proxy variables from the Act environment into the Docker build command.
Hi @john-tipper thanks for the PR !
I've faced a similar issue, and I was trying to rely on the Docker client configuration file, instead of passing environement variables: https://github.com/nektos/act/issues/1578#issuecomment-2077269342 https://docs.docker.com/engine/cli/proxy/#configure-the-docker-client
However, I can't understand yet why Docker skips this client configuration files when invoked through act.
Your PR partially solves this problem by explicitely passing the proxy setting to the Docker build environment, but I believe it doesn't solve the proxy issue when running a container ?
Hi @Wenzel,
I believe the reason your client configuration file is being ignored is because Act is using the Docker API, not the Docker client.
There are several configuration steps that need to be resolved in order for Act to be able to run behind a proxy:
- Configuration of the proxy for building Docker-based GitHub Actions. This allows most normal off-the-shelf third party actions to still work, where they will make calls like
apt updateetc and could not otherwise reach the internet. This is the use case for my PR, where we explicitly pass any proxy variables into the build step of the container action as a build-arg. - Configuration of the Docker daemon so that it can pull containers for building actions. This is done by starting the Docker daemon when suitable HTTP(S)_PROXY and NO_PROXY environmental variables have been set. Running
docker system infowill show if these values have been picked up. Here's an example of doing this in CodeBuild: https://github.com/aws/aws-codebuild-docker-images/issues/355 - Configure any CA certificate bundles into container actions if there are services inside the enterprise environment that use a private CA. This can be done by supplying a
--container-actions -v /path/to/ca.pem:/container/path/to/ca.pem:rcparameter, where the container path will vary according to the flavour of container OS being run. Supplying this multiple times (to cover Ubuntu, Centos/RH, Alpine) should probably cover most bases.
Hi @john-tipper,
thanks to your detailed reply, i learned about --container-options and was able to mount my .docker/config.json:
act --container-options '--mount type=bind,source=/home/mtarral/.docker/config.json,target=/root/.docker/config.json'
The issue was that one of my job was invoking Docker directly, and client is checking for that file to inject the proxy env var into the containers (build or run commands)