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 <[email protected]>
Co-committed-by: Zettat123 <[email protected]>
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 <[email protected]>
Co-authored-by: Marius Zwicker <[email protected]>
Co-committed-by: Marius Zwicker <[email protected]>
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 <[email protected]>
### 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 <[email protected]>
Co-authored-by: techknowlogick <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/228
Reviewed-by: techknowlogick <[email protected]>
Co-authored-by: MarkusLoeffler01 <[email protected]>
Co-committed-by: MarkusLoeffler01 <[email protected]>
- 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 <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/225
Reviewed-by: Jason Song <[email protected]>
Co-authored-by: Bo-Yi Wu <[email protected]>
Co-committed-by: Bo-Yi Wu <[email protected]>
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 <[email protected]>
Co-authored-by: ChristopherHX <[email protected]>
Co-committed-by: ChristopherHX <[email protected]>
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 <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/184
Reviewed-by: Jason Song <[email protected]>
Co-authored-by: sillyguodong <[email protected]>
Co-committed-by: sillyguodong <[email protected]>
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 <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/154
Reviewed-by: Jason Song <[email protected]>
Co-authored-by: Zettat123 <[email protected]>
Co-committed-by: Zettat123 <[email protected]>
### Add secret
```
DOCKERHUB_TOKEN=xxx
```
### Tag
when tag like `v1.0.0`, it will build multi platform docker image `gitea/act_runner:1.0.0` and `gitea/act_runner:latest`, then push to docker hub
### Use
> volume `/data` save `.runner` config file
> volume `/root/.cache` save actcache and actions cache
```sh
docker run -e GITEA_INSTANCE_URL=*** \
-e GITEA_RUNNER_REGISTRATION_TOKEN=*** \
-e GITEA_RUNNER_NAME=*** \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /root/act_runner/data:/data \
-v /root/act_runner/cache:/root/.cache \
gitea/act_runner
```
Test join runners success
Test run action success
Co-authored-by: Jason Song <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/118
Reviewed-by: Jason Song <[email protected]>
Co-authored-by: seepine <[email protected]>
Co-committed-by: seepine <[email protected]>
This adds a very simple Dockerfile and run script for running `act_runner` as a container.
It also allows setting `Privileged` and `ContainerOptions` flags via the new config file when spawning task containers. The combination makes it possible to use Docker-in-Docker (which requires `privileged` mode) as well as pass any other options child Docker containers may require.
For example, if Gitea is running in Docker on the same machine, for the `checkout` action to behave as expected from a task container launched by `act_runner`, it might be necessary to map the hostname via something like:
```
container:
network_mode: bridge
privileged: true
options: --add-host=my.gitea.hostname:host-gateway
```
> NOTE: Description updated to reflect latest code.
> NOTE: Description updated to reflect latest code (again).
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/84
Reviewed-by: Lunny Xiao <[email protected]>
Reviewed-by: Jason Song <[email protected]>
Co-authored-by: Thomas E Lackey <[email protected]>
Co-committed-by: Thomas E Lackey <[email protected]>
Close#21.
Refactor environment variables to configuration file (config.yaml) and registration file (.runner).
The old environment variables are still supported, but warning logs will be printed.
Like:
```text
$ GITEA_DEBUG=true ./act_runner -c config.yaml daemon
INFO[0000] Starting runner daemon
WARN[0000] env GITEA_DEBUG has been ignored because config file is used
$ GITEA_DEBUG=true ./act_runner daemon
INFO[0000] Starting runner daemon
WARN[0000] env GITEA_DEBUG will be deprecated, please use config file instead
```
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/90
Reviewed-by: Lunny Xiao <[email protected]>
Since the `exec` command does not use labels from `.runner`, there is no existing way to specify which Docker image to use for task execution.
This adds an `--image` flag for specifying it manually. The default remains `node:16-bullseye`.
Co-authored-by: Lunny Xiao <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/83
Reviewed-by: Jason Song <[email protected]>
Reviewed-by: Lunny Xiao <[email protected]>
Co-authored-by: telackey <[email protected]>
Co-committed-by: telackey <[email protected]>
Fix#64 (incompletely).
It's still not ideal. It makes more sense to use the gateway IP address of container network as outbound IP of cache server. However, this requires act to cooperate, some think like:
- act creates the network for new container, and returns the network to runner.
- runner extracts the gateway IP in the network.
- runner uses the gateway IP as outbound IP, and pass it to act as cache server endpoint.
- act It continues to create the container with the created network.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/74
Reviewed-by: Lunny Xiao <[email protected]>
The label will follow the format `label[:schema[:args]]`, and the schema will be `host` if it's omitted. So
- `ubuntu:docker://node:18`: Run jobs with label `ubuntu` via docker with image `node:18`
- `ubuntu:host`: Run jobs with label `ubuntu` on the host directly.
- `ubuntu`: Same as `ubuntu:host`.
- `ubuntu:vm:ubuntu-latest`: (Just a example, not Implemented) Run jobs with label `ubuntu` via virtual machine with iso `ubuntu-latest`.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/69
Reviewed-by: Zettat123 <[email protected]>
Reviewed-by: wxiaoguang <[email protected]>
close#42
1. Inject runner version when `make build`
After building, executing command line: `./act_runner -v` or `./act_runner --version`, the version of runner is printed.
2. In `Actions` UI:
3. Set request header in http client interceptor.
Co-authored-by: sillyguodong <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/43
Reviewed-by: delvh <[email protected]>
Reviewed-by: Jason Song <[email protected]>
Co-authored-by: sillyguodong <[email protected]>
Co-committed-by: sillyguodong <[email protected]>
This PR is to fix the wrong last step duration when job failed like shown in the screenshot.
The reason is because when job failed, `Fire` function did not pass in Time, and `r.state.StoppedAt` is by default set to `0001-01-01 08:05:43 +0805 LMT`, which is later on reported to gitea by `UpdateTask`, which calls `UpdateTaskByState` to update the `task.Stopped`, and `task.Stopped` is used in `FullSteps`, resulting in wrong calcaulation of last step duration.
Co-authored-by: nickname <[email protected]>
Co-authored-by: Lunny Xiao <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/41
Reviewed-by: Jason Song <[email protected]>
Reviewed-by: Lunny Xiao <[email protected]>
Co-authored-by: HesterG <[email protected]>
Co-committed-by: HesterG <[email protected]>
If the Workdir field doesn't ends with the filepath seperator,
bad things happen
Fixes#33
Sample for host mode on windows, needs be adjusted for linux e.g. replace pwsh with bash
Also fixes
```yaml
on: push
jobs:
_:
runs-on: self-hosted
steps:
- uses: actions/checkout@v3
with:
path: subdir/action
- uses: ./subdir/action
```
with an action.yml in the same repo
```yaml
runs:
using: composite
steps:
- run: |
echo "Hello World"
shell: pwsh
```
Co-authored-by: Christopher Homberger <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/34
Reviewed-by: Jason Song <[email protected]>
Reviewed-by: Lunny Xiao <[email protected]>
Co-authored-by: ChristopherHX <[email protected]>
Co-committed-by: ChristopherHX <[email protected]>
When deploy a Gitea server with a self-signed HTTPS certification. Runner will be failed when connect to Gitea server. This PR will fix that to allow ignore the HTTPS certification verification.
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/18
Reviewed-by: Jason Song <[email protected]>
Co-authored-by: Lunny Xiao <[email protected]>
Co-committed-by: Lunny Xiao <[email protected]>
The only reason docker is really required by now, is that act_runner ping docker.
This change only pings docker if a label with `docker://` is added to the runner.
Plain labels without `:` like `self-hosted` are run directly on the system. Previously the pseudo non docker label `-self-hosted` have been required like this `self-hosted:docker://-self-hosted`, but due to docker ping this still required a dockerd to be pingable.
Co-authored-by: Christopher Homberger <[email protected]>
Reviewed-on: https://gitea.com/gitea/act_runner/pulls/16
Reviewed-by: Jason Song <[email protected]>
Reviewed-by: Lunny Xiao <[email protected]>
Co-authored-by: ChristopherHX <[email protected]>
Co-committed-by: ChristopherHX <[email protected]>
description:Use this template for reporting bugs/issues.
labels:
- 'kind/bug'
body:
- type:markdown
attributes:
value:|
Thanks for taking the time to fill out this bug report!
- type:textarea
id:act-debug
attributes:
label:Bug report info
render:plain text
description:|
Output of `act --bug-report`
placeholder:|
act --bug-report
validations:
required:true
- type:textarea
id:act-command
attributes:
label:Command used with act
description:|
Please paste your whole command
placeholder:|
act -P ubuntu-latest=node:12 -v -d ...
render:sh
validations:
required:true
- type:textarea
id:what-happened
attributes:
label:Describe issue
description:|
Also tell us what did you expect to happen?
placeholder:|
Describe issue
validations:
required:true
- type:input
id:repo
attributes:
label:Link to GitHub repository
description:|
Provide link to GitHub repository, you can skip it if the repository is private or you don't have it on GitHub, otherwise please provide it as it might help us troubleshoot problem
placeholder:|
https://github.com/nektos/act
validations:
required:false
- type:textarea
id:workflow
attributes:
label:Workflow content
description:|
Please paste your **whole** workflow here
placeholder:|
name: My workflow
on: ['push', 'schedule']
jobs:
test:
runs-on: ubuntu-latest
env:
KEY: VAL
[...]
render:yml
validations:
required:true
- type:textarea
id:logs
attributes:
label:Relevant log output
description:|
Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks. Please verify that the log output doesn't contain any sensitive data.
Help wanted! We'd love your contributions to Act. Please review the following guidelines before contributing. Also, feel free to propose changes to these guidelines by updating this file and submitting a pull request.
- [I have a question...](#questions)
- [I found a bug...](#bugs)
- [I have a feature request...](#features)
- [I have a contribution to share...](#process)
## <a id="questions"></a> Have a Question?
Please don't open a GitHub issue for questions about how to use `act`, as the goal is to use issues for managing bugs and feature requests. Issues that are related to general support will be closed and redirected to our gitter room.
For all support related questions, please ask the question in our gitter room: [nektos/act](https://gitter.im/nektos/act).
## <a id="bugs"></a> Found a Bug?
If you've identified a bug in `act`, please [submit an issue](#issue) to our GitHub repo: [nektos/act](https://github.com/nektos/act/issues/new). Please also feel free to submit a [Pull Request](#pr) with a fix for the bug!
## <a id="features"></a> Have a Feature Request?
All feature requests should start with [submitting an issue](#issue) documenting the user story and acceptance criteria. Again, feel free to submit a [Pull Request](#pr) with a proposed implementation of the feature.
## <a id="process"></a> Ready to Contribute
### <a id="issue"></a> Create an issue
Before submitting a new issue, please search the issues to make sure there isn't a similar issue doesn't already exist.
Assuming no existing issues exist, please ensure you include required information when submitting the issue to ensure we can quickly reproduce your issue.
We may have additional questions and will communicate through the GitHub issue, so please respond back to our questions to help reproduce and resolve the issue as quickly as possible.
New issues can be created with in our [GitHub repo](https://github.com/nektos/act/issues/new).
### <a id="pr"></a>Pull Requests
Pull requests should target the `master` branch. Please also reference the issue from the description of the pull request using [special keyword syntax](https://help.github.com/articles/closing-issues-via-commit-messages/) to auto close the issue when the PR is merged. For example, include the phrase `fixes #14` in the PR description to have issue #14 auto close. Please send documentation updates for the [act user guide](https://nektosact.com) to [nektos/act-docs](https://github.com/nektos/act-docs).
### <a id="style"></a> Styleguide
When submitting code, please make every effort to follow existing conventions and style in order to keep the code as readable as possible. Here are a few points to keep in mind:
- Please run `go fmt ./...` before committing to ensure code aligns with go standards.
- We use [`golangci-lint`](https://golangci-lint.run/) for linting Go code, run `golangci-lint run --fix` before submitting PR. Editors such as Visual Studio Code or JetBrains IntelliJ; with Go support plugin will offer `golangci-lint` automatically.
- There are additional linters and formatters for files such as Markdown documents or YAML/JSON:
- Please refer to the [Makefile](Makefile) or [`lint` job in our workflow](.github/workflows/checks.yml) to see how to those linters/formatters work.
- You can lint codebase by running `go run main.go -j lint --env RUN_LOCAL=true` or `act -j lint --env RUN_LOCAL=true`
- In `Makefile`, there are tools that require `npx` which is shipped with `nodejs`.
- Our `Makefile` exports `GITHUB_TOKEN` from `~/.config/github/token`, you have been warned.
- You can run `make pr` to cleanup dependencies, format/lint code and run tests.
- All dependencies must be defined in the `go.mod` file.
- Advanced IDEs and code editors (like VSCode) will take care of that, but to be sure, run `go mod tidy` to validate dependencies.
- For details on the approved style, check out [Effective Go](https://golang.org/doc/effective_go.html).
- Before running tests, please be aware that they are multi-architecture so for them to not fail, you need to run `docker run --privileged --rm tonistiigi/binfmt --install amd64,arm64` before ([more info available in #765](https://github.com/nektos/act/issues/765)).
Also, consider the original design principles:
- **Polyglot** - There will be no prescribed language or framework for developing the microservices. The only requirement will be that the service will be run inside a container and exposed via an HTTP endpoint.
- **Cloud Provider** - At this point, the tool will assume AWS for the cloud provider and will not be written in a cloud agnostic manner. However, this does not preclude refactoring to add support for other providers at a later time.
- **Declarative** - All resource administration will be handled in a declarative vs. imperative manner. A file will be used to declared the desired state of the resources and the tool will simply assert the actual state matches the desired state. The tool will accomplish this by generating CloudFormation templates.
- **Stateless** - The tool will not maintain its own state. Rather, it will rely on the CloudFormation stacks to determine the state of the platform.
- **Secure** - All security will be managed by AWS IAM credentials. No additional authentication or authorization mechanisms will be introduced.
### License
By contributing your code, you agree to license your contribution under the terms of the [MIT License](LICENSE).
**Warning:** Below badges with size for each image are displaying size of **compressed image size in registry. After pulling the image, size can be drastically different due to Docker uncompressing the image layers.**
## Images based on [`buildpack-deps`][hub/_/buildpack-deps]
**Note 1: `node` images are based on Debian root filesystem, while it is extremely similar to Ubuntu, there might be some differences**
**Note 2: `node` `-slim` images don't have `python` installed, if you want to use actions or software that is depending on `python`, you need to specify image manually**
## Images based on [`actions/virtual-environments`][gh/actions/virtual-environments]
**Note: `nektos/act-environments-ubuntu` have been last updated in February, 2020. It's recommended to update the image manually after `docker pull` if you decide to use it.**
cd$(DIST);for file in `find . -type f -name "*"`;do cp $${file} ./release/;done;
.PHONY:release-check
release-check:|$(DIST_DIRS)
cd$(DIST)/release/;for file in `find . -type f -name "*"`;doecho"checksumming $${file}"&&$(SHASUM)`echo$${file}| sed 's/^..//'` > $${file}.sha256;done;
.PHONY:release-compress
release-compress:|$(DIST_DIRS)
cd$(DIST)/release/;for file in `find . -type f -name "*"`;doecho"compressing $${file}"&&$(GO) run $(GXZ_PAGAGE) -k -9 $${file};done;
This is a custom fork of [nektos/act](https://github.com/nektos/act/), for the purpose of serving [act_runner](https://gitea.com/gitea/act_runner).
Act runner is a runner for Gitea based on [Gitea fork](https://gitea.com/gitea/act) of [act](https://github.com/nektos/act).
It cannot be used as command line tool anymore, but only as a library.
## Installation
It's a soft fork, which means that it will track the latest release of nektos/act.
### Prerequisites
Branches:
Docker Engine Community version is required for docker mode. To install Docker CE, follow the official [install instructions](https://docs.docker.com/engine/install/).
-`main`: default branch, contains custom changes, based on the latest release(not the latest of the master branch) of nektos/act.
-`nektos/master`: mirror for the master branch of nektos/act.
### Download pre-built binary
Tags:
Visit [here](https://dl.gitea.com/act_runner/) and download the right version for your platform.
-`nektos/vX.Y.Z`: mirror for `vX.Y.Z` of [nektos/act](https://github.com/nektos/act/).
-`vX.YZ.*`: based on `nektos/vX.Y.Z`, contains custom changes.
- Examples:
-`nektos/v0.2.23` -> `v0.223.*`
-`nektos/v0.3.1` -> `v0.301.*`, not ~~`v0.31.*`~~
-`nektos/v0.10.1` -> `v0.1001.*`, not ~~`v0.101.*`~~
-`nektos/v0.3.100` -> not ~~`v0.3100.*`~~, I don't think it's really going to happen, if it does, we can find a way to handle it.
# Overview [](https://github.com/nektos/act/actions) [](https://gitter.im/nektos/act?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) [](https://goreportcard.com/report/github.com/nektos/act) [](https://github.com/jonico/awesome-runners)
```bash
make docker
```
> "Think globally, `act` locally"
## Quickstart
Run your [GitHub Actions](https://developer.github.com/actions/) locally! Why would you want to do this? Two reasons:
### Register
- **Fast Feedback** - Rather than having to commit/push every time you want to test out the changes you are making to your `.github/workflows/` files (or for any changes to embedded GitHub actions), you can use `act` to run the actions locally. The [environment variables](https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables) and [filesystem](https://help.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#filesystems-on-github-hosted-runners) are all configured to match what GitHub provides.
- **Local Task Runner** - I love [make](<https://en.wikipedia.org/wiki/Make_(software)>). However, I also hate repeating myself. With `act`, you can use the GitHub Actions defined in your `.github/workflows/` to replace your `Makefile`!
```bash
./act_runner register
```
# How Does It Work?
And you will be asked to input:
When you run `act` it reads in your GitHub Actions from `.github/workflows/` and determines the set of actions that need to be run. It uses the Docker API to either pull or build the necessary images, as defined in your workflow files and finally determines the execution path based on the dependencies that were defined. Once it has the execution path, it then uses the Docker API to run containers for each action based on the images prepared earlier. The [environment variables](https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables) and [filesystem](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#file-systems) are all configured to match what GitHub provides.
1. Gitea instance URL, like `http://192.168.8.8:3000/`. You should use your gitea instance ROOT_URL as the instance argument
and you should not use `localhost` or `127.0.0.1` as instance IP;
2. Runner token, you can get it from `http://192.168.8.8:3000/admin/runners`;
3. Runner name, you can just leave it blank;
4. Runner labels, you can just leave it blank.
Let's see it in action with a [sample repo](https://github.com/cplee/github-actions-demo)!
INFO Registering runner, arch=amd64, os=darwin, version=0.1.5.
WARN Runner in user-mode.
INFO Enter the Gitea instance URL (for example, https://gitea.com/):
http://192.168.8.8:3000/
INFO Enter the runner token:
fe884e8027dc292970d4e0303fe82b14xxxxxxxx
INFO Enter the runner name (if set empty, use hostname: Test.local):
# Act User Guide
INFO Enter the runner labels, leave blank to use the default labels (comma-separated, for example, ubuntu-20.04:docker://node:16-bullseye,ubuntu-18.04:docker://node:16-buster,linux_arm:host):
Please look at the [act user guide](https://nektosact.com) for more documentation.
INFO Registering runner, name=Test.local, instance=http://192.168.8.8:3000/, labels=[ubuntu-latest:docker://node:16-bullseye ubuntu-22.04:docker://node:16-bullseye ubuntu-20.04:docker://node:16-bullseye ubuntu-18.04:docker://node:16-buster].
DEBU Successfully pinged the Gitea instance server
INFO Runner registered successfully.
```
# Support
You can also register with command line arguments.
Need help? Ask on [Gitter](https://gitter.im/nektos/act)!
<!-- Do not remove this test for UTF-8: if “Ω” doesn’t appear as greek uppercase omega letter enclosed in quotation marks, you should use an editor that supports UTF-8, not this one. -->
fmt.Print("\nDetected multiple jobs with the same job name, use `-W` to specify the path to the specific workflow.\n")
}
returnnil
}
Loaded 50 of 1919 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Zettat123
Jason Song
Zettat123
Tomasz Duda
Marius Zwicker
appleboy
sillyguodongandJason Song
ccureauandccureau
a1012112796
Chris Cureauandccureau
harryzcyandharryzcy
ChristopherHX
silverwind
Alex Lau (AvengerMoJo)
sando38andsando38
vbrandlandValentin Brandl
Søren L. HansenandJason Song
seepineandJason Song
techknowlogick
You-Sheng Yang
Lunny Xiao
Thomas E Lackey
fuxiaoheiandJason Song
telackeyandLunny Xiao
Benjamin Loison
sillyguodongandsillyguodong
Zettat123andZettat123
Xinyu Zhou
Jason SongandJason Song
Gitea
GiteaBot