Support automatically available docker functionality #31

New Issue

dboreham · 2023-04-20T22:35:45Z

dboreham commented

2023-04-20 22:35:45 +00:00

Currently because Gitea's act code overrides the execution container's entrypoint, we are not able to initialize the docker deamon transparently. Current workaround is to explicitly start the daemon as a step in each job that uses docker.

This can be fixed in the upstream code by using a command in place of overriding the entrypoint, allowing us to use our own entrypoint script to perform docker start.

In addition, the DOCKER_HOST environment variable needs to end up set correctly.

Currently because Gitea's act code overrides the execution container's entrypoint, we are not able to initialize the docker deamon transparently. Current workaround is to explicitly start the daemon as a step in each job that uses docker. This can be fixed in the upstream code by using a command in place of overriding the entrypoint, allowing us to use our own entrypoint script to perform docker start. In addition, the DOCKER_HOST environment variable needs to end up set correctly.

dboreham commented

2024-01-08 18:05:17 +00:00

Code in Gitea that overrides the entrypoint for the container: https://gitea.com/gitea/act/src/branch/main/pkg/runner/run_context.go#L351
We could try changing that to not override the entrypoint but instead pass the sleep loop as a command

Code in Gitea that overrides the entrypoint for the container: https://gitea.com/gitea/act/src/branch/main/pkg/runner/run_context.go#L351 We could try changing that to not override the entrypoint but instead pass the sleep loop as a command

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

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: cerc-io/hosting#31