This PR
- adds the `cache-server` command so act_runner can run as a cache server. When running as a cache server, act_runner only processes the requests related to cache and does not run jobs.
- adds the `external_server` configuration for cache. If specified, act_runner will use this URL as the ACTIONS_CACHE_URL instead of starting a cache server itself.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/275
Co-authored-by: Zettat123 <zettat123@gmail.com>
Co-committed-by: Zettat123 <zettat123@gmail.com>
Caused by #260
act_runner will fail to start if user does not set `docker_host` configuration and `DOCKER_HOST` env. This PR adds the support for finding docker daemon from common socket paths so act_runner could detect the docker socket from these paths.
The `commonSocketPaths` is from [nektos/act](e60018a6d9/cmd/root.go (L124-L131))
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/263
Co-authored-by: Zettat123 <zettat123@noreply.gitea.com>
Co-committed-by: Zettat123 <zettat123@noreply.gitea.com>
Follow #242, #244Fixes#258
Users could use `docker_host` configuration to specify which docker daemon will be used by act_runner.
- If `docker_host` is **empty**, act_runner will find an available docker host automatically.
- If `docker_host` is **"-"**, 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 `docker_host` is **not empty or "-"**, the specified docker host will be used. An error will be returned if it doesn't work.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/260
Co-authored-by: Zettat123 <zettat123@gmail.com>
Co-committed-by: Zettat123 <zettat123@gmail.com>
allow to pass token from secrets
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/247
Reviewed-by: Jason Song <i@wolfogre.com>
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: Tomasz Duda <tomaszduda23@gmail.com>
Co-committed-by: Tomasz Duda <tomaszduda23@gmail.com>
Adds a new section to the configuration which is used
to control options when running in host mode.
The first option added is to allow configuration
of the location workspaces get created in.
Depends on ~~gitea/act#65~~
Will resolve#235
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/238
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Marius Zwicker <marius.zwicker@mlba-team.de>
Co-committed-by: Marius Zwicker <marius.zwicker@mlba-team.de>
Add env variable to distinguish build run locally from remote one.
Co-authored-by: Jason Song <i@wolfogre.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/246
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Tomasz Duda <tomaszduda23@gmail.com>
Co-committed-by: Tomasz Duda <tomaszduda23@gmail.com>
add --gitea-instance to let user specify address of endpoint of exec
Related to https://gitea.com/gitea/act/pulls/68. Both can be merged independently though.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/245
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Tomasz Duda <tomaszduda23@gmail.com>
Co-committed-by: Tomasz Duda <tomaszduda23@gmail.com>
Follow #242.
Move `docker.host` to `container.docker_host`.
There are already some options for docker/container in `container`, so developers could get confused about where to add options.
It's breaking, but I think it's OK since `docker.host` was added just two days ago.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/244
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Follow https://gitea.com/gitea/act/pulls/60, https://gitea.com/gitea/act/pulls/64
This PR adds the `valid_volumes` configuration. `valid_volumes` is a sequence containing the volumes (including bind mounts) that can be mounted to the container. By default, `valid_volumes` is empty, which means that no volumes can be mounted. Users can specify multiple valid volumes and [glob](https://github.com/gobwas/glob) is supported.
All volumes will be allowed when using `exec` to run workflows locally.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/226
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Zettat123 <zettat123@gmail.com>
Co-committed-by: Zettat123 <zettat123@gmail.com>
1. Print logs on standard output
2. Don't add labels if GITEA_RUNNER_LABELS not set
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/237
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Tomasz Duda <tomaszduda23@gmail.com>
Co-committed-by: Tomasz Duda <tomaszduda23@gmail.com>
This PR creates a rootless Docker image that runs both `dockerd` and `act_runner` using `supervisord`. It has been tested locally for a few days and seems stable.
Co-authored-by: ccureau <ccureau@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/208
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: ccureau <ccureau@noreply.gitea.com>
Co-committed-by: ccureau <ccureau@noreply.gitea.com>
### It's a "simple dirty fix" and I don't have any experiences with Go, so if this doesn't match your coding compliance, please adjust the code as needed
I'm using bash scripts to register a token
`./act_runner/act_runner register --no-interactive --name runner$number --instance http://localhost:3000 --token $token`
But when a token is invalid, the command still returns 0, which is not practical for automation.
A simple non-zero return would be more convenient for power users and developers.
Co-authored-by: Markus Löffler <markus.loeffler@netcare.de>
Co-authored-by: techknowlogick <techknowlogick@noreply.gitea.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/228
Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.com>
Co-authored-by: MarkusLoeffler01 <markusloeffler01@noreply.gitea.com>
Co-committed-by: MarkusLoeffler01 <markusloeffler01@noreply.gitea.com>
- Import "path", "runtime", "strconv", and "strings" packages in daemon.go
- Move "Starting runner daemon" log message to a different location
- Refactor log formatter initialization and add debug level caller information
- Split Config struct into separate Log, Runner, Cache, and Container structs with comments in config.go
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/225
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-committed-by: Bo-Yi Wu <appleboy.tw@gmail.com>
This PR addresses the issue listed in issue #170 regarding how to set up rootless Docker. It also expands on the documentation to show how to create deployments for different environments.
Co-authored-by: ccureau <ccureau@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/207
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Chris Cureau <cmcureau@gmail.com>
Co-committed-by: Chris Cureau <cmcureau@gmail.com>
Related to #184
Add command flag of `network` for `exec`, the default value of `--network` is empty string. Valid values are: `host `, `bridge`, `<custom_network>` and empty string.
Co-authored-by: Jason Song <i@wolfogre.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/192
Reviewed-by: a1012112796 <1012112796@qq.com>
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: sillyguodong <gedong_1994@163.com>
Co-committed-by: sillyguodong <gedong_1994@163.com>
You can currently expose the token to jobs even while using docker in docker
`-e GITEA_RUNNER_REGISTRATION_TOKEN` tells the docker client of act to read GITEA_RUNNER_REGISTRATION_TOKEN from the process and now it can be stolen.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/188
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: ChristopherHX <christopherhx@noreply.gitea.io>
Co-committed-by: ChristopherHX <christopherhx@noreply.gitea.io>
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>
Add some files that belong in every repo.
- `.editorconfig` is based on `gitea` repo.
- `.gitattributes` is useful for Windows users.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/186
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-by: delvh <dev.lh@web.de>
Co-authored-by: silverwind <me@silverwind.io>
Co-committed-by: silverwind <me@silverwind.io>
It is just a typo fix.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/183
Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.io>
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Alex Lau (AvengerMoJo) <avengermojo@gmail.com>
Co-committed-by: Alex Lau (AvengerMoJo) <avengermojo@gmail.com>
This adds tini as a runtime init (https://github.com/krallin/tini). It improves signal handling for the container, see https://github.com/krallin/tini#why-tini.
An alternative could be to run the container with `docker run --init ...` which also places tini as a runtime init as PID 1.
Co-authored-by: sando38 <sandomir@tutanota.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/180
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: sando38 <sando38@noreply.gitea.io>
Co-committed-by: sando38 <sando38@noreply.gitea.io>
- Add `.xz` and `.xz.sha256` files to the release extra files in `.goreleaser.yaml`
upload `.xz` and `.xz.sha256` to Gitea release page.
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-authored-by: Jason Song <i@wolfogre.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/173
Reviewed-by: techknowlogick <techknowlogick@noreply.gitea.io>
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-committed-by: Bo-Yi Wu <appleboy.tw@gmail.com>
- Remove `git=2.38.5-r0` from the `apk add` command in Dockerfile
- Update the download link for act_runner in README.md to be a clickable link
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/172
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-committed-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Fixes#145
At present, the working directory of a work flow is a path like `/<owner>/<repo>`, so the directory may conflict with system directory like `/usr/bin`. We need to add a parent directory for the working directory.
In this PR, the parent directory is `/workspace` by default and users could configure it by the `workdir_parent` option.
This change doesn't affect the host mode because in host mode the working directory will always be in `$HOME/.cache/act/` directory.
Co-authored-by: Jason Song <i@wolfogre.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/154
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Zettat123 <zettat123@gmail.com>
Co-committed-by: Zettat123 <zettat123@gmail.com>
Establishes a simple framework for supporting workflow commands.
Fully implements `::add-mask::`, `::debug::`, and `::stop-commands::`.
Addresses #148
Co-authored-by: Jason Song <i@wolfogre.com>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/149
Reviewed-by: Jason Song <i@wolfogre.com>
Co-authored-by: Søren L. Hansen <sorenisanerd@gmail.com>
Co-committed-by: Søren L. Hansen <sorenisanerd@gmail.com>
