2023-02-28 04:44:46 -06:00
|
|
|
// Copyright 2022 The Gitea Authors. All rights reserved.
|
|
|
|
// SPDX-License-Identifier: MIT
|
|
|
|
|
2022-10-01 23:33:17 -05:00
|
|
|
package config
|
|
|
|
|
|
|
|
import (
|
2023-04-02 09:41:48 -05:00
|
|
|
"fmt"
|
2022-10-01 23:33:17 -05:00
|
|
|
"os"
|
2023-04-02 09:41:48 -05:00
|
|
|
"path/filepath"
|
|
|
|
"time"
|
2022-11-23 21:55:52 -06:00
|
|
|
|
2022-10-01 23:33:17 -05:00
|
|
|
"github.com/joho/godotenv"
|
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 01:46:59 -05:00
|
|
|
log "github.com/sirupsen/logrus"
|
2023-04-02 09:41:48 -05:00
|
|
|
"gopkg.in/yaml.v3"
|
2022-10-01 23:33:17 -05:00
|
|
|
)
|
|
|
|
|
2023-04-02 09:41:48 -05:00
|
|
|
type Config struct {
|
|
|
|
Log struct {
|
|
|
|
Level string `yaml:"level"`
|
|
|
|
} `yaml:"log"`
|
2022-10-01 23:33:17 -05:00
|
|
|
Runner struct {
|
2023-04-05 21:57:36 -05:00
|
|
|
File string `yaml:"file"`
|
|
|
|
Capacity int `yaml:"capacity"`
|
|
|
|
Envs map[string]string `yaml:"envs"`
|
|
|
|
EnvFile string `yaml:"env_file"`
|
|
|
|
Timeout time.Duration `yaml:"timeout"`
|
|
|
|
Insecure bool `yaml:"insecure"`
|
|
|
|
FetchTimeout time.Duration `yaml:"fetch_timeout"`
|
|
|
|
FetchInterval time.Duration `yaml:"fetch_interval"`
|
2023-04-02 09:41:48 -05:00
|
|
|
} `yaml:"runner"`
|
|
|
|
Cache struct {
|
|
|
|
Enabled *bool `yaml:"enabled"` // pointer to distinguish between false and not set, and it will be true if not set
|
|
|
|
Dir string `yaml:"dir"`
|
|
|
|
Host string `yaml:"host"`
|
|
|
|
Port uint16 `yaml:"port"`
|
|
|
|
} `yaml:"cache"`
|
2023-04-04 01:32:01 -05:00
|
|
|
Container struct {
|
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 01:46:59 -05:00
|
|
|
Network string `yaml:"network"`
|
|
|
|
NetworkMode string `yaml:"network_mode"` // Deprecated: use Network instead. Could be removed after Gitea 1.20
|
2023-04-28 09:03:52 -05:00
|
|
|
Privileged bool `yaml:"privileged"`
|
|
|
|
Options string `yaml:"options"`
|
|
|
|
WorkdirParent string `yaml:"workdir_parent"`
|
2023-04-10 21:58:12 -05:00
|
|
|
} `yaml:"container"`
|
2023-04-02 09:41:48 -05:00
|
|
|
}
|
2022-10-01 23:33:17 -05:00
|
|
|
|
2023-04-02 09:41:48 -05:00
|
|
|
// LoadDefault returns the default configuration.
|
|
|
|
// If file is not empty, it will be used to load the configuration.
|
|
|
|
func LoadDefault(file string) (*Config, error) {
|
|
|
|
cfg := &Config{}
|
|
|
|
if file != "" {
|
|
|
|
f, err := os.Open(file)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
2022-11-15 08:42:41 -06:00
|
|
|
}
|
2023-04-02 09:41:48 -05:00
|
|
|
defer f.Close()
|
|
|
|
decoder := yaml.NewDecoder(f)
|
|
|
|
if err := decoder.Decode(&cfg); err != nil {
|
|
|
|
return nil, err
|
2023-02-15 02:51:14 -06:00
|
|
|
}
|
2022-10-15 03:40:35 -05:00
|
|
|
}
|
2023-04-02 09:41:48 -05:00
|
|
|
compatibleWithOldEnvs(file != "", cfg)
|
2022-10-01 23:33:17 -05:00
|
|
|
|
2023-04-02 09:41:48 -05:00
|
|
|
if cfg.Runner.EnvFile != "" {
|
|
|
|
if stat, err := os.Stat(cfg.Runner.EnvFile); err == nil && !stat.IsDir() {
|
|
|
|
envs, err := godotenv.Read(cfg.Runner.EnvFile)
|
|
|
|
if err != nil {
|
|
|
|
return nil, fmt.Errorf("read env file %q: %w", cfg.Runner.EnvFile, err)
|
|
|
|
}
|
|
|
|
for k, v := range envs {
|
|
|
|
cfg.Runner.Envs[k] = v
|
|
|
|
}
|
2022-11-04 04:23:59 -05:00
|
|
|
}
|
2022-10-01 23:33:17 -05:00
|
|
|
}
|
|
|
|
|
2023-04-02 09:41:48 -05:00
|
|
|
if cfg.Log.Level == "" {
|
|
|
|
cfg.Log.Level = "info"
|
2022-10-01 23:33:17 -05:00
|
|
|
}
|
2023-04-02 09:41:48 -05:00
|
|
|
if cfg.Runner.File == "" {
|
|
|
|
cfg.Runner.File = ".runner"
|
2022-10-01 23:33:17 -05:00
|
|
|
}
|
2023-04-02 09:41:48 -05:00
|
|
|
if cfg.Runner.Capacity <= 0 {
|
|
|
|
cfg.Runner.Capacity = 1
|
|
|
|
}
|
|
|
|
if cfg.Runner.Timeout <= 0 {
|
|
|
|
cfg.Runner.Timeout = 3 * time.Hour
|
|
|
|
}
|
|
|
|
if cfg.Cache.Enabled == nil {
|
|
|
|
b := true
|
|
|
|
cfg.Cache.Enabled = &b
|
|
|
|
}
|
|
|
|
if *cfg.Cache.Enabled {
|
|
|
|
if cfg.Cache.Dir == "" {
|
|
|
|
home, _ := os.UserHomeDir()
|
|
|
|
cfg.Cache.Dir = filepath.Join(home, ".cache", "actcache")
|
2022-10-01 23:33:17 -05:00
|
|
|
}
|
|
|
|
}
|
2023-04-28 09:03:52 -05:00
|
|
|
if cfg.Container.WorkdirParent == "" {
|
|
|
|
cfg.Container.WorkdirParent = "workspace"
|
|
|
|
}
|
2023-04-05 21:57:36 -05:00
|
|
|
if cfg.Runner.FetchTimeout <= 0 {
|
|
|
|
cfg.Runner.FetchTimeout = 5 * time.Second
|
|
|
|
}
|
|
|
|
if cfg.Runner.FetchInterval <= 0 {
|
|
|
|
cfg.Runner.FetchInterval = 2 * time.Second
|
|
|
|
}
|
2022-10-01 23:33:17 -05:00
|
|
|
|
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 01:46:59 -05:00
|
|
|
// although `container.network_mode` will be deprecated, but we have to be compatible with it for now.
|
|
|
|
if cfg.Container.NetworkMode != "" && cfg.Container.Network == "" {
|
|
|
|
log.Warn("You are trying to use deprecated configuration item of `container.network_mode`, please use `container.network` instead.")
|
|
|
|
if cfg.Container.NetworkMode == "bridge" {
|
|
|
|
// Previously, if the value of `container.network_mode` is `bridge`, we will create a new network for job.
|
|
|
|
// But “bridge” is easily confused with the bridge network created by Docker by default.
|
|
|
|
// So we set the value of `container.network` to empty string to make `act_runner` automatically create a new network for job.
|
|
|
|
cfg.Container.Network = ""
|
|
|
|
} else {
|
|
|
|
cfg.Container.Network = cfg.Container.NetworkMode
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-10-15 03:12:32 -05:00
|
|
|
return cfg, nil
|
2022-10-01 23:33:17 -05:00
|
|
|
}
|