act icon indicating copy to clipboard operation
act copied to clipboard

Act should pass proxy build args when building Docker actions

Open john-tipper opened this issue 1 year ago • 4 comments

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.

john-tipper avatar Apr 05 '25 19:04 john-tipper

PR submitted, where --pass-proxy-vars-to-docker-build will pass the proxy variables from the Act environment into the Docker build command.

john-tipper avatar Apr 05 '25 19:04 john-tipper

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 ?

Wenzel avatar Apr 09 '25 14:04 Wenzel

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:

  1. 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 update etc 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.
  2. 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 info will 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
  3. 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:rc parameter, 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.

john-tipper avatar Apr 10 '25 13:04 john-tipper

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)

Wenzel avatar Apr 11 '25 13:04 Wenzel