[GH-ISSUE #2722] Act should pass proxy build args when building Docker actions #1229

Open
opened 2026-03-01 21:49:49 +03:00 by kerem · 4 comments
Owner

Originally created by @john-tipper on GitHub (Apr 5, 2025).
Original GitHub issue: https://github.com/nektos/act/issues/2722

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.

Originally created by @john-tipper on GitHub (Apr 5, 2025). Original GitHub issue: https://github.com/nektos/act/issues/2722 ### 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.
Author
Owner

@john-tipper commented on GitHub (Apr 5, 2025):

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

<!-- gh-comment-id:2781055000 --> @john-tipper commented on GitHub (Apr 5, 2025): PR submitted, where `--pass-proxy-vars-to-docker-build` will pass the proxy variables from the Act environment into the Docker build command.
Author
Owner

@Wenzel commented on GitHub (Apr 9, 2025):

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 ?

<!-- gh-comment-id:2789860208 --> @Wenzel commented on GitHub (Apr 9, 2025): 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 ?
Author
Owner

@john-tipper commented on GitHub (Apr 10, 2025):

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.
<!-- gh-comment-id:2792785751 --> @john-tipper commented on GitHub (Apr 10, 2025): 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.
Author
Owner

@Wenzel commented on GitHub (Apr 11, 2025):

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)

<!-- gh-comment-id:2796894622 --> @Wenzel commented on GitHub (Apr 11, 2025): 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)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/act#1229
No description provided.