2023-04-02 22:41:48 +08:00
# Example configuration file, it's safe to copy this as the default config file without any modification.
2023-07-20 10:16:30 +08:00
# You don't have to copy this file to your instance,
# just run `./act_runner generate-config > config.yaml` to generate a config file.
2023-04-02 22:41:48 +08:00
log :
# The level of logging, can be trace, debug, info, warn, error, fatal
level : info
runner :
# Where to store the registration result.
file : .runner
# Execute how many tasks concurrently at the same time.
capacity : 1
# Extra environment variables to run jobs.
envs :
A_TEST_ENV_NAME_1 : a_test_env_value_1
A_TEST_ENV_NAME_2 : a_test_env_value_2
# Extra environment variables to run jobs from a file.
# It will be ignored if it's empty or the file doesn't exist.
env_file : .env
# The timeout for a job to be finished.
# Please note that the Gitea instance also has a timeout (3h by default) for the job.
# So the job could be stopped by the Gitea instance if it's timeout is shorter than this.
timeout : 3h
2024-05-27 15:38:55 +08:00
# The timeout for the runner to wait for running jobs to finish when shutting down.
# Any running jobs that haven't finished after this timeout will be cancelled.
shutdown_timeout : 0s
2023-04-02 22:41:48 +08:00
# Whether skip verifying the TLS certificate of the Gitea instance.
insecure : false
2023-04-06 10:57:36 +08:00
# The timeout for fetching the job from the Gitea instance.
fetch_timeout : 5s
# The interval for fetching the job from the Gitea instance.
fetch_interval : 2s
2023-06-15 11:59:15 +08:00
# The labels of a runner are used to determine which jobs the runner can run, and how to run them.
2024-04-02 15:38:14 +08:00
# Like: "macos-arm64:host" or "ubuntu-latest:docker://gitea/runner-images:ubuntu-latest"
# Find more images provided by Gitea at https://gitea.com/gitea/runner-images .
2023-06-15 11:59:15 +08:00
# If it's empty when registering, it will ask for inputting labels.
2024-04-02 15:38:14 +08:00
# If it's empty when execute `daemon`, will use labels in `.runner` file.
labels :
- "ubuntu-latest:docker://gitea/runner-images:ubuntu-latest"
- "ubuntu-22.04:docker://gitea/runner-images:ubuntu-22.04"
- "ubuntu-20.04:docker://gitea/runner-images:ubuntu-20.04"
2023-04-02 22:41:48 +08:00
cache :
# Enable cache server to use actions/cache.
enabled : true
# The directory to store the cache data.
# If it's empty, the cache data will be stored in $HOME/.cache/actcache.
dir : ""
# The host of the cache server.
# It's not for the address to listen, but the address to connect from job containers.
# So 0.0.0.0 is a bad choice, leave it empty to detect automatically.
host : ""
# The port of the cache server.
# 0 means to use a random available port.
port : 0
2023-07-07 16:28:54 +08:00
# The external cache server URL. Valid only when enable is true.
# If it's specified, act_runner will use this URL as the ACTIONS_CACHE_URL rather than start a server by itself.
# The URL should generally end with "/".
external_server : ""
2023-04-04 14:32:01 +08:00
container :
Add configuration item of `container.network` (#184)
Close https://gitea.com/gitea/act_runner/issues/177
Related https://gitea.com/gitea/act/pulls/56
### ⚠️ Breaking
The `container.network_mode` is a deprecated configuration item. It may be removed after Gitea 1.20 released.
Previously, if the value of `container.network_mode` is `bridge`, it means that `act_runner` will create a new network for job.But `bridge` is easily confused with the bridge network created by Docker by default.
We recommand that using `container.network` to specify the network to which containers created by `act_runner` connect.
### 🆕 container.network
The configuration file of `act_runner` add a new item of `contianer.network`.
In `config.example.yaml`:
```yaml
container:
# Specifies the network to which the container will connect.
# Could be host, bridge or the name of a custom network.
# If it's empty, act_runner will create a network automatically.
network: ""
```
As the comment in the example above says, the purpose of the `container.network` is specifying the network to which containers created by `act_runner` will connect.
`container.network` accepts the following valid values:
- `host`: All of containers (including job containers and service contianers) created by `act_runner` will be connected to the network named `host` which is created automatically by Docker. Containers will share the host’s network stack and all interfaces from the host will be available to these containers.
- `bridge`: It is similar to `host`. All of containers created by `act_runner` will be connected to the network named `bridge` which is created automatically by Docker. All containers connected to the `bridge` (Perhaps there are containers that are not created by `act_runner`) are allowed to communicate with each other, while providing isolation from containers which are not connected to that `bridge` network.
- `<custom_network>`: Please make sure that the `<custom_network>` network already exists firstly (`act_runner` does not detect whether the specified network exists currently. If not exists yet, will return error in the stage of `docker create`). All of containers created by `act_runner` will be connected to `<custom_network>`. After the job is executed, containers are removed and automatically disconnected from the `<custom_network>`.
- empty: `act_runner` will create a new network for each job container and their service containers (if defined in workflow). So each job container and their service containers share a network environment, but are isolated from others container and the Docker host. Of course, these networks created by `act_runner` will be removed at last.
### Others
- If you do not have special needs, we highly recommend that setting `container.network` to empty string (and do not use `container.network_mode` any more). Because the containers created by `act_runner` will connect to the networks that are created by itself. This point will provide better isolation.
- If you set `contianer.network` to empty string or `<custom_network>`, we can be access to service containers by `<service-id>:<port>` in the steps of job. Because we added an alias to the service container when connecting to the network.
Co-authored-by: Jason Song <i@wolfogre.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/184
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: sillyguodong <gedong_1994@163.com>
Co-committed-by: sillyguodong <gedong_1994@163.com>
2023-05-16 14:46:59 +08:00
# Specifies the network to which the container will connect.
# Could be host, bridge or the name of a custom network.
# If it's empty, act_runner will create a network automatically.
network : ""
2023-04-11 10:58:12 +08:00
# Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker).
privileged : false
# And other options to be used when the container is started (eg, --add-host=my.gitea.url:host-gateway).
options :
2023-04-28 22:03:52 +08:00
# The parent directory of a job's working directory.
2024-03-22 10:30:31 +08:00
# NOTE: There is no need to add the first '/' of the path as act_runner will add it automatically.
# If the path starts with '/', the '/' will be trimmed.
# For example, if the parent directory is /path/to/my/dir, workdir_parent should be path/to/my/dir
2023-04-28 22:03:52 +08:00
# If it's empty, /workspace will be used.
workdir_parent :
2023-06-16 14:07:48 +08:00
# Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob
# You can specify multiple volumes. If the sequence is empty, no volumes can be mounted.
# For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to:
# valid_volumes:
# - data
# - /src/*.json
# If you want to allow any volume, please use the following configuration:
# valid_volumes:
# - '**'
valid_volumes : [ ]
2023-06-18 13:38:38 +08:00
# overrides the docker client host with the specified one.
2023-06-30 12:00:04 +08:00
# If it's empty, act_runner will find an available docker host automatically.
# If it's "-", act_runner will find an available docker host automatically, but the docker host won't be mounted to the job containers and service containers.
# If it's not empty or "-", the specified docker host will be used. An error will be returned if it doesn't work.
2023-06-19 17:01:16 +08:00
docker_host : ""
2023-08-17 14:51:57 +08:00
# Pull docker image(s) even if already present
2024-04-02 15:38:14 +08:00
force_pull : true
2023-12-20 15:13:33 +08:00
# Rebuild docker image(s) even if already present
force_rebuild : false
2023-06-20 16:29:05 +08:00
host :
# The parent directory of a job's working directory.
# If it's empty, $HOME/.cache/act/ will be used.
workdir_parent :