diff options
author | John Olheiser <john.olheiser@gmail.com> | 2023-07-25 23:53:13 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-07-26 04:53:13 +0000 |
commit | bd4c7ce578956d9839309b16753bd5505b63b2e3 (patch) | |
tree | 1d3074ef542cee11707bc4985ce54dc40facb9b6 /docs/content/usage/actions | |
parent | 5dc37ef97a30628027a723ee944225a33a6511f8 (diff) | |
download | gitea-bd4c7ce578956d9839309b16753bd5505b63b2e3.tar.gz gitea-bd4c7ce578956d9839309b16753bd5505b63b2e3.zip |
Docusaurus-ify (#26051)
This PR cleans up the docs in a way to make them simpler to ingest by
our [docs repo](https://gitea.com/gitea/gitea-docusaurus).
1. It includes all of the sed invocations our ingestion did, removing
the need to do it at build time.
2. It replaces the shortcode variable replacement method with
`@variable@` style, simply for easier sed invocations when required.
3. It removes unused files and moves the docs up a level as cleanup.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
Diffstat (limited to 'docs/content/usage/actions')
-rw-r--r-- | docs/content/usage/actions/act-runner.en-us.md | 263 | ||||
-rw-r--r-- | docs/content/usage/actions/act-runner.zh-cn.md | 259 | ||||
-rw-r--r-- | docs/content/usage/actions/comparison.en-us.md | 167 | ||||
-rw-r--r-- | docs/content/usage/actions/comparison.zh-cn.md | 167 | ||||
-rw-r--r-- | docs/content/usage/actions/design.en-us.md | 131 | ||||
-rw-r--r-- | docs/content/usage/actions/design.zh-cn.md | 132 | ||||
-rw-r--r-- | docs/content/usage/actions/faq.en-us.md | 182 | ||||
-rw-r--r-- | docs/content/usage/actions/faq.zh-cn.md | 182 | ||||
-rw-r--r-- | docs/content/usage/actions/overview.en-us.md | 51 | ||||
-rw-r--r-- | docs/content/usage/actions/overview.zh-cn.md | 51 | ||||
-rw-r--r-- | docs/content/usage/actions/quickstart.en-us.md | 141 | ||||
-rw-r--r-- | docs/content/usage/actions/quickstart.zh-cn.md | 140 |
12 files changed, 1866 insertions, 0 deletions
diff --git a/docs/content/usage/actions/act-runner.en-us.md b/docs/content/usage/actions/act-runner.en-us.md new file mode 100644 index 0000000000..05ed83c2c4 --- /dev/null +++ b/docs/content/usage/actions/act-runner.en-us.md @@ -0,0 +1,263 @@ +--- +date: "2023-04-27T15:00:00+08:00" +title: "Act Runner" +slug: "act-runner" +sidebar_position: 20 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "Act Runner" + sidebar_position: 20 + identifier: "actions-runner" +--- + +# Act Runner + +This page will introduce the [act runner](https://gitea.com/gitea/act_runner) in detail, which is the runner of Gitea Actions. + +## Requirements + +It is recommended to run jobs in a docker container, so you need to install docker first. +And make sure that the docker daemon is running. + +Other OCI container engines which are compatible with Docker's API should also work, but are untested. + +However, if you are sure that you want to run jobs directly on the host only, then docker is not required. + +## Installation + +There are multiple ways to install the act runner. + +### Download the binary + +You can download the binary from the [release page](https://gitea.com/gitea/act_runner/releases). +However, if you want to use the latest nightly build, you can download it from the [download page](https://dl.gitea.com/act_runner/). + +When you download the binary, please make sure that you have downloaded the correct one for your platform. +You can check it by running the following command: + +```bash +chmod +x act_runner +./act_runner --version +``` + +If you see the version information, it means that you have downloaded the correct binary. + +### Use the docker image + +You can use the docker image from the [docker hub](https://hub.docker.com/r/gitea/act_runner/tags). +Just like the binary, you can use the latest nightly build by using the `nightly` tag, while the `latest` tag is the latest stable release. + +```bash +docker pull gitea/act_runner:latest # for the latest stable release +docker pull gitea/act_runner:nightly # for the latest nightly build +``` + +## Configuration + +Configuration is done via a configuration file. It is optional, and the default configuration will be used when no configuration file is specified. + +You can generate a configuration file by running the following command: + +```bash +./act_runner generate-config +``` + +The default configuration is safe to use without any modification, so you can just use it directly. + +```bash +./act_runner generate-config > config.yaml +./act_runner --config config.yaml [command] +``` + +You could also generate config file with docker: + +```bash +docker run --entrypoint="" --rm -it gitea/act_runner:latest act_runner generate-config > config.yaml +``` + +When you are using the docker image, you can specify the configuration file by using the `CONFIG_FILE` environment variable. Make sure that the file is mounted into the container as a volume: + +```bash +docker run -v $(pwd)/config.yaml:/config.yaml -e CONFIG_FILE=/config.yaml ... +``` + +You may notice the commands above are both incomplete, because it is not the time to run the act runner yet. +Before running the act runner, we need to register it to your Gitea instance first. + +## Registration + +Registration is required before running the act runner, because the runner needs to know where to get jobs from. +And it is also important to Gitea instance to identify the runner. + +### Runner levels + +You can register a runner in different levels, it can be: + +- Instance level: The runner will run jobs for all repositories in the instance. +- Organization level: The runner will run jobs for all repositories in the organization. +- Repository level: The runner will run jobs for the repository it belongs to. + +Note that the repository may still use instance-level or organization-level runners even if it has its own repository-level runners. A future release may provide an option to allow more control over this. + +### Obtain a registration token + +The level of the runner determines where to obtain the registration token. + +- Instance level: The admin settings page, like `<your_gitea.com>/admin/actions/runners`. +- Organization level: The organization settings page, like `<your_gitea.com>/<org>/settings/actions/runners`. +- Repository level: The repository settings page, like `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`. + +If you cannot see the settings page, please make sure that you have the right permissions and that Actions have been enabled. + +The format of the registration token is a random string `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`. + +### Register the runner + +The act runner can be registered by running the following command: + +```bash +./act_runner register +``` + +Alternatively, you can use the `--config` option to specify the configuration file mentioned in the previous section. + +```bash +./act_runner --config config.yaml register +``` + +You will be asked to input the registration information step by step. Includes: + +- The Gitea instance URL, like `https://gitea.com/` or `http://192.168.8.8:3000/`. +- The registration token. +- The runner name, which is optional. If you leave it blank, the hostname will be used. +- The runner labels, which is optional. If you leave it blank, the default labels will be used. + +You may be confused about the runner labels, which will be explained later. + +If you want to register the runner in a non-interactive way, you can use arguments to do it. + +```bash +./act_runner register --no-interactive --instance <instance_url> --token <registration_token> --name <runner_name> --labels <runner_labels> +``` + +When you have registered the runner, you can find a new file named `.runner` in the current directory. +This file stores the registration information. +Please do not edit it manually. +If this file is missing or corrupted, you can simply remove it and register again. + +If you want to store the registration information in another place, you can specify it in the configuration file, +and don't forget to specify the `--config` option. + +### Register the runner with docker + +If you are using the docker image, behaviour will be slightly different. Registration and running are combined into one step in this case, so you need to specify the registration information when running the act runner. + +```bash +docker run \ + -v $(pwd)/config.yaml:/config.yaml \ + -v $(pwd)/data:/data \ + -v /var/run/docker.sock:/var/run/docker.sock \ + -e CONFIG_FILE=/config.yaml \ + -e GITEA_INSTANCE_URL=<instance_url> \ + -e GITEA_RUNNER_REGISTRATION_TOKEN=<registration_token> \ + -e GITEA_RUNNER_NAME=<runner_name> \ + -e GITEA_RUNNER_LABELS=<runner_labels> \ + --name my_runner \ + -d gitea/act_runner:nightly +``` + +You may notice that we have mounted the `/var/run/docker.sock` into the container. +It is because the act runner will run jobs in docker containers, so it needs to communicate with the docker daemon. +As mentioned, you can remove it if you want to run jobs in the host directly. +To be clear, the "host" actually means the container which is running the act runner now, instead of the host machine. + +### Set up the runner using docker compose + +You could also set up the runner using the following `docker-compose.yml`: + +```yml +version: "3.8" +services: + runner: + image: gitea/act_runner:nightly + environment: + CONFIG_FILE: /config.yaml + GITEA_INSTANCE_URL: "${INSTANCE_URL}" + GITEA_RUNNER_REGISTRATION_TOKEN: "${REGISTRATION_TOKEN}" + GITEA_RUNNER_NAME: "${RUNNER_NAME}" + GITEA_RUNNER_LABELS: "${RUNNER_LABELS}" + volumes: + - ./config.yaml:/config.yaml + - ./data:/data + - /var/run/docker.sock:/var/run/docker.sock +``` + +### Configuring cache when starting a Runner using docker image + +If you do not intend to use `actions/cache` in workflow, you can ignore this section. + +If you use `actions/cache` without any additional configuration, it will return the following error: +> Failed to restore: getCacheEntry failed: connect ETIMEDOUT IP:PORT + +The error occurs because the runner container and job container are on different networks, so the job container cannot access the runner container. + +Therefore, it is essential to configure the cache action to ensure its proper functioning. Follow these steps: + +- 1.Obtain the LAN IP address of the host machine where the runner container is running. +- 2.Find an available port number on the host machine where the runner container is running. +- 3.Configure the following settings in the configuration file: + +```yaml +cache: + enabled: true + dir: "" + # Use the LAN IP obtained in step 1 + host: "192.168.8.17" + # Use the port number obtained in step 2 + port: 8088 +``` + +- 4.When starting the container, map the cache port to the host machine: + +```bash +docker run \ + --name gitea-docker-runner \ + -p 8088:8088 \ + -d gitea/act_runner:nightly +``` + +### Labels + +The labels of a runner are used to determine which jobs the runner can run, and how to run them. + +The default labels are `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`. +It is a comma-separated list, and each item is a label. + +Let's take `ubuntu-22.04:docker://node:16-bullseye` as an example. +It means that the runner can run jobs with `runs-on: ubuntu-22.04`, and the job will be run in a docker container with the image `node:16-bullseye`. + +If the default image is insufficient for your needs, and you have enough disk space to use a better and bigger one, you can change it to `ubuntu-22.04:docker://<the image you like>`. +You can find more useful images on [act images](https://github.com/nektos/act/blob/master/IMAGES.md). + +If you want to run jobs in the host directly, you can change it to `ubuntu-22.04:host` or just `ubuntu-22.04`, the `:host` is optional. +However, we suggest you to use a special name like `linux_amd64:host` or `windows:host` to avoid misusing it. + +One more thing is that it is recommended to register the runner if you want to change the labels. +It may be annoying to do this, so we may provide a better way to do it in the future. + +## Running + +After you have registered the runner, you can run it by running the following command: + +```bash +./act_runner daemon +# or +./act_runner daemon --config config.yaml +``` + +The runner will fetch jobs from the Gitea instance and run them automatically. + +Since act runner is still in development, it is recommended to check the latest version and upgrade it regularly. diff --git a/docs/content/usage/actions/act-runner.zh-cn.md b/docs/content/usage/actions/act-runner.zh-cn.md new file mode 100644 index 0000000000..c3978f6361 --- /dev/null +++ b/docs/content/usage/actions/act-runner.zh-cn.md @@ -0,0 +1,259 @@ +--- +date: "2023-05-24T15:00:00+08:00" +title: "Act Runner" +slug: "act-runner" +sidebar_position: 20 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "Act Runner" + sidebar_position: 20 + identifier: "actions-runner" +--- + +# Act Runner + +本页面将详细介绍[Act Runner](https://gitea.com/gitea/act_runner),这是Gitea Actions的Runner。 + +## 要求 + +建议在Docker容器中运行Job,因此您需要首先安装Docker。 +并确保Docker守护进程正在运行。 + +其他与Docker API兼容的OCI容器引擎也应该可以正常工作,但尚未经过测试。 + +但是,如果您确定要直接在主机上运行Job,则不需要Docker。 + +## 安装 + +有多种安装Act Runner的方法。 + +### 下载二进制文件 + +您可以从[发布页面](https://gitea.com/gitea/act_runner/releases)下载二进制文件。 +然而,如果您想使用最新的夜间构建版本,可以从[下载页面](https://dl.gitea.com/act_runner/)下载。 + +下载二进制文件时,请确保您已经下载了适用于您的平台的正确版本。 +您可以通过运行以下命令进行检查: + +```bash +chmod +x act_runner +./act_runner --version +``` + +如果看到版本信息,则表示您已经下载了正确的二进制文件。 + +### 使用 Docker 镜像 + +您可以使用[docker hub](https://hub.docker.com/r/gitea/act_runner/tags)上的Docker镜像。 +与二进制文件类似,您可以使用`nightly`标签使用最新的夜间构建版本,而`latest`标签是最新的稳定版本。 + +```bash +docker pull gitea/act_runner:latest # for the latest stable release +docker pull gitea/act_runner:nightly # for the latest nightly build +``` + +## 配置 + +配置通过配置文件进行。它是可选的,当没有指定配置文件时,将使用默认配置。 + +您可以通过运行以下命令生成配置文件: + +```bash +./act_runner generate-config +``` + +默认配置是安全的,可以直接使用。 + +```bash +./act_runner generate-config > config.yaml +./act_runner --config config.yaml [command] +``` + +您亦可以如下使用 docker 创建配置文件: + +```bash +docker run --entrypoint="" --rm -it gitea/act_runner:latest act_runner generate-config > config.yaml +``` + +当使用Docker镜像时,可以使用`CONFIG_FILE`环境变量指定配置文件。确保将文件作为卷挂载到容器中: + +```bash +docker run -v $(pwd)/config.yaml:/config.yaml -e CONFIG_FILE=/config.yaml ... +``` + +您可能注意到上面的命令都是不完整的,因为现在还不是运行Act Runner的时候。 +在运行Act Runner之前,我们需要首先将其注册到您的Gitea实例中。 + +## 注册 + +在运行Act Runner之前,需要进行注册,因为Runner需要知道从哪里获取Job,并且对于Gitea实例来说,识别Runner也很重要。 + +### Runner级别 + +您可以在不同级别上注册Runner,它可以是: + +- 实例级别:Runner将为实例中的所有存储库运行Job。 +- 组织级别:Runner将为组织中的所有存储库运行Job。 +- 存储库级别:Runner将为其所属的存储库运行Job。 + +请注意,即使存储库具有自己的存储库级别Runner,它仍然可以使用实例级别或组织级别Runner。未来的版本可能提供更多对此进行更好控制的选项。 + +### 获取注册令牌 + +Runner级别决定了从哪里获取注册令牌。 + +- 实例级别:管理员设置页面,例如 `<your_gitea.com>/admin/actions/runners`。 +- 组织级别:组织设置页面,例如 `<your_gitea.com>/<org>/settings/actions/runners`。 +- 存储库级别:存储库设置页面,例如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。 + +如果您无法看到设置页面,请确保您具有正确的权限并且已启用 Actions。 + +注册令牌的格式是一个随机字符串 `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`。 + +### 注册Runner + +可以通过运行以下命令来注册Act Runner: + +```bash +./act_runner register +``` + +或者,您可以使用 `--config` 选项来指定前面部分提到的配置文件。 + +```bash +./act_runner --config config.yaml register +``` + +您将逐步输入注册信息,包括: + +- Gitea 实例的 URL,例如 `https://gitea.com/` 或 `http://192.168.8.8:3000/`。 +- 注册令牌。 +- Runner名称(可选)。如果留空,将使用主机名。 +- Runner标签(可选)。如果留空,将使用默认标签。 + +您可能对Runner标签感到困惑,稍后将对其进行解释。 + +如果您想以非交互方式注册Runner,可以使用参数执行以下操作。 + +```bash +./act_runner register --no-interactive --instance <instance_url> --token <registration_token> --name <runner_name> --labels <runner_labels> +``` + +注册Runner后,您可以在当前目录中找到一个名为 `.runner` 的新文件。该文件存储注册信息。 +请不要手动编辑该文件。 +如果此文件丢失或损坏,可以直接删除它并重新注册。 + +如果您想将注册信息存储在其他位置,请在配置文件中指定,并不要忘记指定 `--config` 选项。 + +### 使用Docker注册Runner + +如果您使用的是Docker镜像,注册行为会略有不同。在这种情况下,注册和运行合并为一步,因此您需要在运行Act Runner时指定注册信息。 + +```bash +docker run \ + -v $(pwd)/config.yaml:/config.yaml \ + -v $(pwd)/data:/data \ + -v /var/run/docker.sock:/var/run/docker.sock \ + -e CONFIG_FILE=/config.yaml \ + -e GITEA_INSTANCE_URL=<instance_url> \ + -e GITEA_RUNNER_REGISTRATION_TOKEN=<registration_token> \ + -e GITEA_RUNNER_NAME=<runner_name> \ + -e GITEA_RUNNER_LABELS=<runner_labels> \ + --name my_runner \ + -d gitea/act_runner:nightly +``` + +您可能注意到我们已将`/var/run/docker.sock`挂载到容器中。 +这是因为Act Runner将在Docker容器中运行Job,因此它需要与Docker守护进程进行通信。 +如前所述,如果要在主机上直接运行Job,可以将其移除。 +需要明确的是,这里的 "主机" 实际上指的是当前运行 Act Runner的容器,而不是主机机器本身。 + +### 使用 Docker compose 运行 Runner + +您亦可使用如下的 `docker-compose.yml`: + +```yml +version: "3.8" +services: + runner: + image: gitea/act_runner:nightly + environment: + CONFIG_FILE: /config.yaml + GITEA_INSTANCE_URL: "${INSTANCE_URL}" + GITEA_RUNNER_REGISTRATION_TOKEN: "${REGISTRATION_TOKEN}" + GITEA_RUNNER_NAME: "${RUNNER_NAME}" + GITEA_RUNNER_LABELS: "${RUNNER_LABELS}" + volumes: + - ./config.yaml:/config.yaml + - ./data:/data + - /var/run/docker.sock:/var/run/docker.sock +``` + +### 当您使用 Docker 镜像启动 Runner,如何配置 Cache + +如果你不打算在工作流中使用 `actions/cache`,你可以忽略本段。 + +如果您在使用 `actions/cache` 时没有进行额外的配置,将会返回以下错误信息: +> Failed to restore: getCacheEntry failed: connect ETIMEDOUT IP:PORT + +这个错误的原因是 runner 容器和作业容器位于不同的网络中,因此作业容器无法访问 runner 容器。 +因此,配置 cache 动作以确保其正常运行是非常重要的。请按照以下步骤操作: + +- 1.获取 Runner 容器所在主机的 LAN(本地局域网) IP 地址。 +- 2.获取一个 Runner 容器所在主机的空闲端口号。 +- 3.在配置文件中如下配置: + +```yaml +cache: +enabled: true +dir: "" +# 使用步骤 1. 获取的 LAN IP +host: "192.168.8.17" +# 使用步骤 2. 获取的端口号 +port: 8088 +``` + +- 4.启动容器时, 将 Cache 端口映射至主机。 + +```bash +docker run \ + --name gitea-docker-runner \ + -p 8088:8088 \ + -d gitea/act_runner:nightly +``` + +### 标签 + +Runner的标签用于确定Runner可以运行哪些Job以及如何运行它们。 + +默认标签为`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`。 +它们是逗号分隔的列表,每个项目都是一个标签。 + +让我们以 `ubuntu-22.04:docker://node:16-bullseye` 为例。 +它意味着Runner可以运行带有`runs-on: ubuntu-22.04`的Job,并且该Job将在使用`node:16-bullseye`镜像的Docker容器中运行。 + +如果默认镜像无法满足您的需求,并且您有足够的磁盘空间可以使用更好、更大的镜像,您可以将其更改为`ubuntu-22.04:docker://<您喜欢的镜像>`。 +您可以在[act 镜像](https://github.com/nektos/act/blob/master/IMAGES.md)上找到更多有用的镜像。 + +如果您想直接在主机上运行Job,您可以将其更改为`ubuntu-22.04:host`或仅`ubuntu-22.04`,`:host`是可选的。 +然而,我们建议您使用类似`linux_amd64:host`或`windows:host`的特殊名称,以避免误用。 + +还有一点需要注意的是,建议在更改标签时注册Runner。 +这可能会有些麻烦,所以我们可能会在将来提供更好的方法来处理。 + +## 运行 + +注册完Runner后,您可以通过运行以下命令来运行它: + +```bash +./act_runner daemon +# or +./act_runner daemon --config config.yaml +``` + +Runner将从Gitea实例获取Job并自动运行它们。 + +由于Act Runner仍处于开发中,建议定期检查最新版本并进行升级。 diff --git a/docs/content/usage/actions/comparison.en-us.md b/docs/content/usage/actions/comparison.en-us.md new file mode 100644 index 0000000000..64a5eff4d5 --- /dev/null +++ b/docs/content/usage/actions/comparison.en-us.md @@ -0,0 +1,167 @@ +--- +date: "2023-04-27T15:00:00+08:00" +title: "Compared to GitHub Actions" +slug: "comparison" +sidebar_position: 30 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "Comparison" + sidebar_position: 30 + identifier: "actions-comparison" +--- + +# Compared to GitHub Actions + +Even though Gitea Actions is designed to be compatible with GitHub Actions, there are some differences between them. + +## Additional features + +### Absolute action URLs + +Gitea Actions supports defining actions via absolute URL, which means that you can use actions from any git repository. +Like `uses: https://github.com/actions/checkout@v3` or `uses: http://your_gitea.com/owner/repo@branch`. + +### Actions written in Go + +Gitea Actions supports writing actions in Go. +See [Creating Go Actions](https://blog.gitea.com/creating-go-actions/). + +## Unsupported workflows syntax + +### `concurrency` + +It's used to run a single job at a time. +See [Using concurrency](https://docs.github.com/en/actions/using-jobs/using-concurrency). + +It's ignored by Gitea Actions now. + +### `run-name` + +The name for workflow runs generated from the workflow. +See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#run-name). + +It's ignored by Gitea Actions now. + +### `permissions` and `jobs.<job_id>.permissions` + +See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions). + +It's ignored by Gitea Actions now. + +### `jobs.<job_id>.timeout-minutes` + +See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes). + +It's ignored by Gitea Actions now. + +### `jobs.<job_id>.continue-on-error` + +See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error). + +It's ignored by Gitea Actions now. + +### `jobs.<job_id>.environment` + +See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment). + +It's ignored by Gitea Actions now. + +### Complex `runs-on` + +See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on). + +Gitea Actions only supports `runs-on: xyz` or `runs-on: [xyz]` now. + +### `workflow_dispatch` + +See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatch). + +It's ignored by Gitea Actions now. + +### `hashFiles` expression + +See [Expressions](https://docs.github.com/en/actions/learn-github-actions/expressions#hashfiles) + +Gitea Actions doesn't support it now, if you use it, the result will always be empty string. + +As a workaround, you can use [go-hashfiles](https://gitea.com/actions/go-hashfiles) instead. + +## Missing features + +### Variables + +See [Variables](https://docs.github.com/en/actions/learn-github-actions/variables). + +It's under development. + +### Problem Matchers + +Problem Matchers are a way to scan the output of actions for a specified regex pattern and surface that information prominently in the UI. +See [Problem matchers](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md). + +It's ignored by Gitea Actions now. + +### Create an error annotation + +See [Creating an annotation for an error](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error) + +It's ignored by Gitea Actions now. + +## Missing UI features + +### Pre and Post steps + +Pre and Post steps don't have their own section in the job log user interface. + +## Different behavior + +### Downloading actions + +Gitea Actions doesn't download actions from GitHub by default. +"By default" means that you don't specify the host in the `uses` field, like `uses: actions/checkout@v3`. +As a contrast, `uses: https://github.com/actions/checkout@v3` has specified host. + +The missing host will be filled with `https://gitea.com` if you don't configure it. +That means `uses: actions/checkout@v3` will download the action from [gitea.com/actions/checkout](https://gitea.com/actions/checkout), instead of [github.com/actions/checkout](https://github.com/actions/checkout). + +As mentioned, it's configurable. +If you want your runners to download actions from GitHub or your own Gitea instance by default, you can configure it by setting `[actions].DEFAULT_ACTIONS_URL`. See [Configuration Cheat Sheet](administration/config-cheat-sheet.md#actions-actions). + +### Context availability + +Context availability is not checked, so you can use the env context on more places. +See [Context availability](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability). + +## Known issues + +### `docker/build-push-action@v4` + +See [act_runner#119](https://gitea.com/gitea/act_runner/issues/119#issuecomment-738294). + +`ACTIONS_RUNTIME_TOKEN` is a random string in Gitea Actions, not a JWT. +But the `docker/build-push-action@v4` tries to parse the token as JWT and doesn't handle the error, so the job fails. + +There are two workarounds: + +Set the `ACTIONS_RUNTIME_TOKEN` to empty manually, like: + +``` yml +- name: Build and push + uses: docker/build-push-action@v4 + env: + ACTIONS_RUNTIME_TOKEN: '' + with: +... +``` + +The bug has been fixed in a newer [commit](https://gitea.com/docker/build-push-action/commit/d8823bfaed2a82c6f5d4799a2f8e86173c461aba?style=split&whitespace=show-all#diff-1af9a5bdf96ddff3a2f3427ed520b7005e9564ad), but it has not been released. So you could use the latest version by specifying the branch name, like: + +``` yml +- name: Build and push + uses: docker/build-push-action@master + with: +... +``` diff --git a/docs/content/usage/actions/comparison.zh-cn.md b/docs/content/usage/actions/comparison.zh-cn.md new file mode 100644 index 0000000000..cfea7970f7 --- /dev/null +++ b/docs/content/usage/actions/comparison.zh-cn.md @@ -0,0 +1,167 @@ +--- +date: "2023-05-24T15:00:00+08:00" +title: "与GitHub Actions的对比" +slug: "comparison" +sidebar_position: 30 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "对比" + sidebar_position: 30 + identifier: "actions-comparison" +--- + +# 与GitHub Actions的对比 + +尽管Gitea Actions旨在与GitHub Actions兼容,但它们之间存在一些差异。 + +## 额外功能 + +### Action URL绝对路径 + +Gitea Actions支持通过URL绝对路径定义actions,这意味着您可以使用来自任何Git存储库的Actions。 +例如,`uses: https://github.com/actions/checkout@v3`或`uses: http://your_gitea.com/owner/repo@branch`。 + +### 使用Go编写Actions + +Gitea Actions支持使用Go编写Actions。 +请参阅[创建Go Actions](https://blog.gitea.com/creating-go-actions/)。 + +## 不支持的工作流语法 + +### `concurrency` + +这是用于一次运行一个Job。 +请参阅[使用并发](https://docs.github.com/zh/actions/using-jobs/using-concurrency)。 + +Gitea Actions目前不支持此功能。 + +### `run-name` + +这是工作流生成的工作流运行的名称。 +请参阅[GitHub Actions 的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#run-name)。 + +Gitea Actions目前不支持此功能。 + +### `permissions`和`jobs.<job_id>.permissions` + +请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#permissions)。 + +Gitea Actions目前不支持此功能。 + +### `jobs.<job_id>.timeout-minutes` + +请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes)。 + +Gitea Actions目前不支持此功能。 + +### `jobs.<job_id>.continue-on-error` + +请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error)。 + +Gitea Actions目前不支持此功能。 + +### `jobs.<job_id>.environment` + +请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment)。 + +Gitea Actions 目前不支持此功能。 + +### 复杂的`runs-on` + +请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)。 + +Gitea Actions目前只支持`runs-on: xyz`或`runs-on: [xyz]`。 + +### `workflow_dispatch` + +请参阅[GitHub Actions的工作流语法](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#onworkflow_dispatch)。 + +Gitea Actions目前不支持此功能。 + +### `hashFiles`表达式 + +请参阅[表达式](https://docs.github.com/en/actions/learn-github-actions/expressions#hashfiles)。 + +Gitea Actions目前不支持此功能,如果使用它,结果将始终为空字符串。 + +作为解决方法,您可以使用[go-hashfiles](https://gitea.com/actions/go-hashfiles)。 + +## 缺失的功能 + +### 变量 + +请参阅[变量](https://docs.github.com/zh/actions/learn-github-actions/variables)。 + +目前变量功能正在开发中。 + +### 问题匹配器 + +问题匹配器是一种扫描Actions输出以查找指定正则表达式模式并在用户界面中突出显示该信息的方法。 +请参阅[问题匹配器](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md)。 + +Gitea Actions目前不支持此功能。 + +### 为错误创建注释 + +请参阅[为错误创建注释](https://docs.github.com/zh/actions/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error)。 + +Gitea Actions目前不支持此功能。 + +## 缺失的UI功能 + +### 预处理和后处理步骤 + +预处理和后处理步骤在Job日志用户界面中没有自己的用户界面。 + +## 不一样的行为 + +### 下载Actions + +Gitea Actions默认不从GitHub下载Actions。 +"默认" 意味着您在`uses` 字段中不指定主机,如`uses: actions/checkout@v3`。 +相反,`uses: https://github.com/actions/checkout@v3`是有指定主机的。 + +如果您不进行配置,缺失的主机将填充为`https://gitea.com`。 +这意味着`uses: actions/checkout@v3`将从[gitea.com/actions/checkout](https://gitea.com/actions/checkout)下载该Action,而不是[github.com/actions/checkout](https://github.com/actions/checkout)。 + +正如前面提到的,这是可配置的。 +如果您希望您的运行程序默认从GitHub或您自己的Gitea实例下载动作,您可以通过设置`[actions].DEFAULT_ACTIONS_URL`进行配置。请参阅[配置备忘单](administration/config-cheat-sheet.md#actions-actions)。 + +### 上下文可用性 + +不检查上下文可用性,因此您可以在更多地方使用env上下文。 +请参阅[上下文可用性](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability)。 + +## 已知问题 + +### `docker/build-push-action@v4` + +请参阅[act_runner#119](https://gitea.com/gitea/act_runner/issues/119#issuecomment-738294)。 + +`ACTIONS_RUNTIME_TOKEN`在Gitea Actions中是一个随机字符串,而不是JWT。 +但是`DOCKER/BUILD-PUSH-ACTION@V4尝试将令牌解析为JWT,并且不处理错误,因此Job失败。 + +有两种解决方法: + +手动将`ACTIONS_RUNTIME_TOKEN`设置为空字符串,例如: + +``` yml +- name: Build and push + uses: docker/build-push-action@v4 + env: + ACTIONS_RUNTIME_TOKEN: '' + with: +... +``` + +该问题已在较新的[提交](https://gitea.com/docker/build-push-action/commit/d8823bfaed2a82c6f5d4799a2f8e86173c461aba?style=split&whitespace=show-all#diff-1af9a5bdf96ddff3a2f3427ed520b7005e9564ad)中修复,但尚未发布。因此,您可以通过指定分支名称来使用最新版本,例如: + +``` yml +- name: Build and push + uses: docker/build-push-action@master + with: +... +``` diff --git a/docs/content/usage/actions/design.en-us.md b/docs/content/usage/actions/design.en-us.md new file mode 100644 index 0000000000..d4c90d5404 --- /dev/null +++ b/docs/content/usage/actions/design.en-us.md @@ -0,0 +1,131 @@ +--- +date: "2023-04-27T15:00:00+08:00" +title: "Design of Gitea Actions" +slug: "design" +sidebar_position: 40 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "Design" + sidebar_position: 40 + identifier: "actions-design" +--- + +# Design of Gitea Actions + +Gitea Actions has multiple components. This document describes them individually. + +## Act + +The [nektos/act](https://github.com/nektos/act) project is an excellent tool that allows you to run your GitHub Actions locally. +We were inspired by this and wondered if it would be possible to run actions for Gitea. + +However, while [nektos/act](https://github.com/nektos/act) is designed as a command line tool, what we actually needed was a Go library with modifications specifically for Gitea. +So we forked it as [gitea/act](https://gitea.com/gitea/act). + +This is a soft fork that will periodically follow the upstream. +Although some custom commits have been added, we will try our best to avoid changing too much of the original code. + +The forked act is just a shim or adapter for Gitea's specific usage. +There are some additional commits that have been made, such as: + +- Outputting execution logs to logger hook so they can be reported to Gitea +- Disabling the GraphQL URL, since Gitea doesn't support it +- Starting a new container for every job instead of reusing to ensure isolation. + +These modifications have no reason to be merged into the upstream. +They don't make sense if the user just wants to run trusted actions locally. + +However, there may be overlaps in the future, such as a required bug fix or new feature needed by both projects. +In these cases, we will contribute the changes back to the upstream repository. + +## Act runner + +Gitea's runner is called act runner because it's based on act. + +Like other CI runners, we designed it as an external part of Gitea, which means it should run on a different server than Gitea. + +To ensure that the runner connects to the correct Gitea instance, we need to register it with a token. +Additionally, the runner will introduce itself to Gitea and declare what kind of jobs it can run by reporting its labels. + +Earlier, we mentioned that `runs-on: ubuntu-latest` in a workflow file means that the job will be run on a runner with the `ubuntu-latest` label. +But how does the runner know to run `ubuntu-latest`? The answer lies in mapping the label to an environment. +That's why when you add custom labels during registration, you will need to input some complex content like `my_custom_label:docker://centos:7`. +This means that the runner can take the job which needs to run on `my_custom_label`, and it will run it via a docker container with the image `centos:7`. + +Docker isn't the only option, though. +The act also supports running jobs directly on the host. +This is achieved through labels like `linux_arm:host`. +This label indicates that the runner can take a job that needs to run on `linux_arm` and run it directly on the host. + +The label's design follows the format `label[:schema[:args]]`. +If the schema is omitted, it defaults to `host`. +So, + +- `my_custom_label:docker://node:18`: Run jobs labeled with `my_custom_label` using the `node:18` Docker image. +- `my_custom_label:host`: Run jobs labeled with `my_custom_label` directly on the host. +- `my_custom_label`: Same as `my_custom_label:host`. +- `my_custom_label:vm:ubuntu-latest`: (Example only, not implemented) Run jobs labeled with `my_custom_label` using a virtual machine with the `ubuntu-latest` ISO. + +## Communication protocol + +As act runner is an independent part of Gitea, we needed a protocol for runners to communicate with the Gitea instance. +However, we did not think it was a good idea to have Gitea listen on a new port. +Instead, we wanted to reuse the HTTP port, which means we needed a protocol that is compatible with HTTP. +We chose to use gRPC over HTTP. + +We use [actions-proto-def](https://gitea.com/gitea/actions-proto-def) and [actions-proto-go](https://gitea.com/gitea/actions-proto-go) to wire them up. +More information about gRPC can be found on [its website](https://grpc.io/). + +## Network architecture + +Let's examine the overall network architecture. +This will help you troubleshoot some problems and explain why it's a bad idea to register a runner with a loopback address of the Gitea instance. + +![network](/images/usage/actions/network.png) + +There are four network connections marked in the picture, and the direction of the arrows indicates the direction of establishing the connections. + +### Connection 1, act runner to Gitea instance + +The act runner must be able to connect to Gitea to receive tasks and send back the execution results. + +### Connection 2, job containers to Gitea instance + +The job containers have different network namespaces than the runner, even if they are on the same machine. +They need to connect to Gitea to fetch codes if there is `actions/checkout@v3` in the workflow, for example. +Fetching code is not always necessary to run some jobs, but it is required in most cases. + +If you use a loopback address to register a runner, the runner can connect to Gitea when it is on the same machine. +However, if a job container tries to fetch code from localhost, it will fail because Gitea is not in the same container. + +### Connection 3, act runner to internet + +When you use some actions like `actions/checkout@v3`, the act runner downloads the scripts, not the job containers. +By default, it downloads from [gitea.com](http://gitea.com/), so it requires access to the internet. +It also downloads some docker images from Docker Hub by default, which also requires internet access. + +However, internet access is not strictly necessary. +You can configure your Gitea instance to fetch actions or images from your intranet facilities. + +In fact, your Gitea instance can serve as both the actions marketplace and the image registry. +You can mirror actions repositories from GitHub to your Gitea instance, and use them as normal. +And [Gitea Container Registry](https://docs.gitea.io/en-us/usage/packages/container/) can be used as a Docker image registry. + +### Connection 4, job containers to internet + +When using actions such as `actions/setup-go@v4`, it may be necessary to download resources from the internet to set up the Go language environment in job containers. +Therefore, access to the internet is required for the successful completion of these actions. + +However, it is optional as well. +You can use your own custom actions to avoid relying on internet access, or you can use your packaged Docker image to run jobs with all dependencies installed. + +## Summary + +Using Gitea Actions only requires ensuring that the runner can connect to the Gitea instance. +Internet access is optional, but not having it will require some additional work. +In other words: The runner works best when it can query the internet itself, but you don't need to expose it to the internet (in either direction). + +If you encounter any network issues while using Gitea Actions, hopefully the image above can help you troubleshoot them. diff --git a/docs/content/usage/actions/design.zh-cn.md b/docs/content/usage/actions/design.zh-cn.md new file mode 100644 index 0000000000..995e9f0b7f --- /dev/null +++ b/docs/content/usage/actions/design.zh-cn.md @@ -0,0 +1,132 @@ +--- +date: "2023-05-24T15:00:00+08:00" +title: "Gitea Actions设计" +slug: "design" +sidebar_position: 40 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "设计" + sidebar_position: 40 + identifier: "actions-design" +--- + +# Gitea Actions设计 + +Gitea Actions由多个组件组成。本文档将对它们进行逐个描述。 + +## Act + +[nektos/act](https://github.com/nektos/act) 项目是一个优秀的工具,允许你在本地运行GitHub Actions。 +我们受到了它的启发,并思考它是否可能为Gitea运行Actions。 + +然而,尽管[nektos/act](https://github.com/nektos/act)被设计为一个命令行工具,但我们实际上需要的是一个专为Gitea修改的Go库。 +因此,我们在[gitea/act](https://gitea.com/gitea/act)基础上进行了分叉。 + +这是一个软分叉,将定期跟进上游。 +虽然添加了一些自定义提交,但我们会尽力避免对原始代码进行太多更改。 + +分叉的 act 只是Gitea特定用途的桥接或适配器。 +还添加了一些额外的提交,例如: + +- 将执行日志输出到日志记录器钩子,以便报告给Gitea +- 禁用 GraphQL URL,因为Gitea不支持它 +- 每个Job启动一个新的容器,而不是重复使用,以确保隔离性。 + +这些修改没有理由合并到上游。 +如果用户只想在本地运行可信的Actions,它们是没有意义的。 + +然而,将来可能会出现重叠,例如两个项目都需要的必要错误修复或新功能。 +在这些情况下,我们将向上游仓库贡献变更。 + +## act runner + +Gitea的Runner被称为act runner,因为它基于act。 + +与其他CIRunner一样,我们将其设计为Gitea的外部部分,这意味着它应该在与Gitea不同的服务器上运行。 + +为了确保Runner连接到正确的Gitea实例,我们需要使用令牌注册它。 +此外,Runner通过声明自己的标签向Gitea报告它可以运行的Job类型。 + +之前,我们提到工作流文件中的 `runs-on: ubuntu-latest` 表示该Job将在具有`ubuntu-latest`标签的Runner上运行。 +但是,Runner如何知道要运行 `ubuntu-latest`?答案在于将标签映射到环境。 +这就是为什么在注册过程中添加自定义标签时,需要输入一些复杂内容,比如`my_custom_label:docker://centos:7`。 +这意味着Runner可以接受需要在`my_custom_label`上运行的Job,并通过使用`centos:7`镜像的Docker容器来运行它。 + +然而,Docker不是唯一的选择。 +act 也支持直接在主机上运行Job。 +这是通过像`linux_arm:host`这样的标签实现的。 +这个标签表示Runner可以接受需要在`linux_arm`上运行的Job,并直接在主机上运行它们。 + +标签的设计遵循格式`label[:schema[:args]]`。 +如果省略了schema,则默认为`host`。 + +因此, + +- `my_custom_label:docker://node:18`:使用`node:18 Docker`镜像运行带有`my_custom_label`标签的Job。 +- `my_custom_label:host`:在主机上直接运行带有`my_custom_label`标签的Job。 +- `my_custom_label`:等同于`my_custom_label:host`。 +- `my_custom_label:vm:ubuntu-latest`:(仅为示例,未实现)使用带有`ubuntu-latest` ISO的虚拟机运行带有`my_custom_label`标签的Job。 + +## 通信协议 + +由于act runner是Gitea的独立部分,我们需要一种协议让Runner与Gitea实例进行通信。 +然而,我们不认为让Gitea监听一个新端口是个好主意。 +相反,我们希望重用HTTP端口,这意味着我们需要一个与HTTP兼容的协议。 +因此,我们选择使用基于HTTP的gRPC。 + +我们使用[actions-proto-def](https://gitea.com/gitea/actions-proto-def) 和 [actions-proto-go](https://gitea.com/gitea/actions-proto-go) 进行连接。 +有关 gRPC 的更多信息,请访问[其官方网站](https://grpc.io/)。 + +## 网络架构 + +让我们来看一下整体的网络架构。 +这将帮助您解决一些问题,并解释为什么使用回环地址注册Runner是个不好的主意。 + +![network](/images/usage/actions/network.png) + +图片中标记了四个网络连接,并且箭头的方向表示建立连接的方向。 + +### 连接 1,act runner到Gitea实例 + +act runner 必须能够连接到Gitea以接收任务并发送执行结果回来。 + +### 连接 2,Job容器到Gitea实例 + +即使Job容器位于同一台机器上,它们的网络命名空间与Runner不同。 +举个例子,如果工作流中包含 `actions/checkout@v3`,Job容器需要连接到Gitea来获取代码。 +获取代码并不总是运行某些Job所必需的,但在大多数情况下是必需的。 + +如果您使用回环地址注册Runner,当Runner与Gitea在同一台机器上时,Runner可以连接到Gitea。 +然而,如果Job容器尝试从本地主机获取代码,它将失败,因为Gitea不在同一个容器中。 + +### 连接 3,act runner到互联网 + +当您使用诸如 `actions/checkout@v3` 的一些Actions时,act runner下载的是脚本,而不是Job容器。 +默认情况下,它从[gitea.com](http://gitea.com/)下载,因此需要访问互联网。 +它还默认从Docker Hub下载一些Docker镜像,这也需要互联网访问。 + +然而,互联网访问并不是绝对必需的。 +您可以配置您的Gitea实例从您的内部网络设施中获取 Actions 或镜像。 + +实际上,您的Gitea实例可以同时充当 Actions 市场和镜像注册表。 +您可以将GitHub上的Actions仓库镜像到您的Gitea实例,并将其用作普通Actions。 +而 [Gitea 容器注册表](https://docs.gitea.io/en-us/usage/packages/container/) 可用作Docker镜像注册表。 + +### 连接 4,Job容器到互联网 + +当使用诸如`actions/setup-go@v4`的Actions时,可能需要从互联网下载资源,以设置Job容器中的Go语言环境。 +因此,成功完成这些Actions需要访问互联网。 + +然而,这也是可选的。 +您可以使用自定义的Actions来避免依赖互联网访问,或者可以使用已安装所有依赖项的打包的Docker镜像来运行Job。 + +## 总结 + +使用Gitea Actions只需要确保Runner能够连接到Gitea实例。 +互联网访问是可选的,但如果没有互联网访问,将需要额外的工作。 +换句话说:当Runner能够自行查询互联网时,它的工作效果最好,但您不需要将其暴露给互联网(无论是单向还是双向)。 + +如果您在使用Gitea Actions时遇到任何网络问题,希望上面的图片能够帮助您进行故障排除。 diff --git a/docs/content/usage/actions/faq.en-us.md b/docs/content/usage/actions/faq.en-us.md new file mode 100644 index 0000000000..d665b05b4b --- /dev/null +++ b/docs/content/usage/actions/faq.en-us.md @@ -0,0 +1,182 @@ +--- +date: "2023-04-27T15:00:00+08:00" +title: "Frequently Asked Questions of Gitea Actions" +slug: "faq" +sidebar_position: 100 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "FAQ" + sidebar_position: 100 + identifier: "actions-faq" +--- + +# Frequently Asked Questions of Gitea Actions + +This page contains some common questions and answers about Gitea Actions. + +## Why is Actions not enabled by default? + +We know it's annoying to enable Actions for the whole instance and each repository one by one, but not everyone likes or needs this feature. +We believe that more work needs to be done to improve Gitea Actions before it deserves any further special treatment. + +## Is it possible to enable Actions for new repositories by default for my own instance? + +Yes, when you enable Actions for the instance, you can choose to enable the `actions` unit for all new repositories by default. + +```ini +[repository] +DEFAULT_REPO_UNITS = ...,repo.actions +``` + +## Should we use `${{ github.xyz }}` or `${{ gitea.xyz }}` in workflow files? + +You can use `github.xyz` and Gitea will work fine. +As mentioned, Gitea Actions is designed to be compatible with GitHub Actions. +However, we recommend using `gitea.xyz` in case Gitea adds something that GitHub does not have to avoid different kinds of secrets in your workflow file (and because you are using this workflow on Gitea, not GitHub). +Still, this is completely optional since both options have the same effect at the moment. + +## Is it possible to register runners for a specific user (not organization)? + +Not yet. +It is technically possible to implement, but we need to discuss whether it is necessary. + +## Where will the runner download scripts when using actions such as `actions/checkout@v3`? + +You may be aware that there are tens of thousands of [marketplace actions](https://github.com/marketplace?type=actions) in GitHub. +However, when you write `uses: actions/checkout@v3`, it actually downloads the scripts from [gitea.com/actions/checkout](http://gitea.com/actions/checkout) by default (not GitHub). +This is a mirror of [github.com/actions/checkout](http://github.com/actions/checkout), but it's impossible to mirror all of them. +That's why you may encounter failures when trying to use some actions that haven't been mirrored. + +The good news is that you can specify the URL prefix to use actions from anywhere. +This is an extra syntax in Gitea Actions. +For example: + +- `uses: https://github.com/xxx/xxx@xxx` +- `uses: https://gitea.com/xxx/xxx@xxx` +- `uses: http://your_gitea_instance.com/xxx@xxx` + +Be careful, the `https://` or `http://` prefix is necessary! + +Alternatively, if you want your runners to download actions from GitHub or your own Gitea instance by default, you can configure it by setting `[actions].DEFAULT_ACTIONS_URL`. +See [Configuration Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions). + +This is one of the differences from GitHub Actions, but it should allow users much more flexibility in how they run Actions. + +## How to limit the permission of the runners? + +Runners have no more permissions than simply connecting to your Gitea instance. +When any runner receives a job to run, it will temporarily gain limited permission to the repository associated with the job. +If you want to give more permissions to the runner, allowing it to access more private repositories or external systems, you can pass [secrets](https://docs.gitea.io/en-us/usage/secrets/) to it. + +Refined permission control to Actions is a complicated job. +In the future, we will add more options to Gitea to make it more configurable, such as allowing more write access to repositories or read access to all repositories in the same organization. + +## How to avoid being hacked? + +There are two types of possible attacks: unknown runner stealing the code or secrets from your repository, or malicious scripts controlling your runner. + +Avoiding the former means not allowing people you don't know to register runners for your repository, organization, or instance. + +The latter is a bit more complicated. +If you're using a private Gitea instance for your company, you may not need to worry about security since you trust your colleagues and can hold them accountable. + +For public instances, things are a little different. +Here's how we do it on [gitea.com](http://gitea.com/): + +- We only register runners for the "gitea" organization, so our runners will not execute jobs from other repositories. +- Our runners always run jobs with isolated containers. While it is possible to do this directly on the host, we choose not to for more security. +- To run actions for fork pull requests, approval is required. See [#22803](https://github.com/go-gitea/gitea/pull/22803). +- If someone registers their own runner for their repository or organization on [gitea.com](http://gitea.com/), we have no objections and will just not use it in our org. However, they should take care to ensure that the runner is not used by other users they do not know. + +## Which operating systems are supported by act runner? + +It works well on Linux, macOS, and Windows. +While other operating systems are theoretically supported, they require further testing. + +One thing to note is that if you choose to run jobs directly on the host instead of in job containers, the environmental differences between operating systems may cause unexpected failures. + +For example, bash is not available on Windows in most cases, while act tries to use bash to run scripts by default. +Therefore, you need to specify `powershell` as the default shell in your workflow file, see [defaults.run](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun). + +```yaml +defaults: + run: + shell: powershell +``` + +## Why choose GitHub Actions? Why not something compatible with GitLab CI/CD? + +[@lunny](https://gitea.com/lunny) has explained this in the [issue to implement actions](https://github.com/go-gitea/gitea/issues/13539). +Furthermore, Actions is not only a CI/CD system but also an automation tool. + +There have also been numerous [marketplace actions](https://github.com/marketplace?type=actions) implemented in the open-source world. +It is exciting to be able to reuse them. + +## What if it runs on multiple labels, such as `runs-on: [label_a, label_b]`? + +This is valid syntax. +It means that it should run on runners that have both the `label_a` **and** `label_b` labels, see [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on). +Unfortunately, act runner does not work this way. +As mentioned, we map labels to environments: + +- `ubuntu` → `ubuntu:22.04` +- `centos` → `centos:8` + +But we need to map label groups to environments instead, like so: + +- `[ubuntu]` → `ubuntu:22.04` +- `[with-gpu]` → `linux:with-gpu` +- `[ubuntu, with-gpu]` → `ubuntu:22.04_with-gpu` + +We also need to re-design how tasks are assigned to runners. +A runner with `ubuntu`, `centos`, or `with-gpu` does not necessarily indicate that it can accept jobs with `[centos, with-gpu]`. +Therefore, the runner should inform the Gitea instance that it can only accept jobs with `[ubuntu]`, `[centos]`, `[with-gpu]`, and `[ubuntu, with-gpu]`. +This is not a technical problem, it was just overlooked in the early design. +See [runtime.go#L65](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65). + +Currently, the act runner attempts to match everyone in the labels and uses the first match it finds. + +## What is the difference between agent labels and custom labels for a runner? + +![labels](/images/usage/actions/labels.png) + +Agent labels are reported to the Gitea instance by the runner during registration. +Custom labels, on the other hand, are added manually by a Gitea administrator or owners of the organization or repository (depending on the level of the runner). + +However, the design here needs improvement, as it currently has some rough edges. +You can add a custom label such as `centos` to a registered runner, which means the runner will receive jobs with `runs-on: centos`. +However, the runner may not know which environment to use for this label, resulting in it using a default image or leading to a logical dead end. +This default may not match user expectations. +See [runtime.go#L71](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71). + +In the meantime, we suggest that you re-register your runner if you want to change its labels. + +## Will there be more implementations for Gitea Actions runner? + +Although we would like to provide more options, our limited manpower means that act runner will be the only officially supported runner. +However, both Gitea and act runner are completely open source, so anyone can create a new/better implementation. +We support your choice, no matter how you decide. +In case you fork act runner to create your own version: Please contribute the changes back if you can and if you think your changes will help others as well. + +## What workflow trigger events does Gitea support? + +All events listed in this table are supported events and are compatible with GitHub. +For events supported only by GitHub, see GitHub's [documentation](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows). + +| trigger event | activity types | +|-----------------------------|--------------------------------------------------------------------------------------------------------------------------| +| create | not applicable | +| delete | not applicable | +| fork | not applicable | +| gollum | not applicable | +| push | not applicable | +| issues | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `milestoned`, `demilestoned`, `labeled`, `unlabeled` | +| issue_comment | `created`, `edited`, `deleted` | +| pull_request | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `synchronize`, `labeled`, `unlabeled` | +| pull_request_review | `submitted`, `edited` | +| pull_request_review_comment | `created`, `edited` | +| release | `published`, `edited` | +| registry_package | `published` | diff --git a/docs/content/usage/actions/faq.zh-cn.md b/docs/content/usage/actions/faq.zh-cn.md new file mode 100644 index 0000000000..cdfea6d11d --- /dev/null +++ b/docs/content/usage/actions/faq.zh-cn.md @@ -0,0 +1,182 @@ +--- +date: "2023-05-24T15:00:00+08:00" +title: "Gitea Actions常见问题解答" +slug: "faq" +sidebar_position: 100 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "常见问题" + sidebar_position: 100 + identifier: "actions-faq" +--- + +# Gitea Actions常见问题解答 + +本页面包含一些关于Gitea Actions的常见问题和答案。 + +## 为什么默认情况下不启用Actions? + +我们知道为整个实例和每个仓库启用Actions可能很麻烦,但并不是每个人都喜欢或需要此功能。 +在我们认为Gitea Actions值得被特别对待之前,我们认为还需要做更多的工作来改进它。 + +## 是否可以在我的实例中默认启用新仓库的Actions? + +是的,当您为实例启用Actions时,您可以选择默认启用actions单元以适用于所有新仓库。 + +```ini +[repository] +DEFAULT_REPO_UNITS = ...,repo.actions +``` + +## 在工作流文件中应该使用`${{ github.xyz }}`还是`${{ gitea.xyz }}`? + +您可以使用`github.xyz`,Gitea将正常工作。 +如前所述,Gitea Actions的设计是与GitHub Actions兼容的。 +然而,我们建议在工作流文件中使用`gitea.xyz`,以防止在工作流文件中出现不同类型的密钥(因为您在Gitea上使用此工作流,而不是GitHub)。 +不过,这完全是可选的,因为目前这两个选项的效果是相同的。 + +## 是否可以为特定用户(而不是组织)注册Runner? + +目前还不可以。 +从技术上讲是可以实现的,但我们需要讨论是否有必要。 + +## 使用`actions/checkout@v3`等Actions时,Job容器会从何处下载脚本? + +您可能知道GitHub上有成千上万个[Actions市场](https://github.com/marketplace?type=actions)。 +然而,当您编写`uses: actions/checkout@v3`时,它实际上默认从[gitea.com/actions/checkout](http://gitea.com/actions/checkout)下载脚本(而不是从GitHub下载)。 +这是[github.com/actions/checkout](http://github.com/actions/checkout)的镜像,但无法将它们全部镜像。 +这就是为什么在尝试使用尚未镜像的某些Actions时可能会遇到失败的原因。 + +好消息是,您可以指定要从任何位置使用Actions的URL前缀。 +这是Gitea Actions中的额外语法。 +例如: + +- `uses: https://github.com/xxx/xxx@xxx` +- `uses: https://gitea.com/xxx/xxx@xxx` +- `uses: http://your_gitea_instance.com/xxx@xxx` + +注意,`https://`或`http://`前缀是必需的! + +另外,如果您希望您的Runner默认从GitHub或您自己的Gitea实例下载Actions,可以通过设置 `[actions].DEFAULT_ACTIONS_URL`进行配置。 +参见[配置速查表](https://docs.gitea.io/en-us/config-cheat-sheet/#actions-actions)。 + +这是与GitHub Actions的一个区别,但它应该允许用户以更灵活的方式运行Actions。 + +## 如何限制Runner的权限? + +Runner仅具有连接到您的Gitea实例的权限。 +当任何Runner接收到要运行的Job时,它将临时获得与Job关联的仓库的有限权限。 +如果您想为Runner提供更多权限,允许它访问更多私有仓库或外部系统,您可以向其传递[密钥](https://docs.gitea.io/en-us/usage/secrets/)。 + +对于 Actions 的细粒度权限控制是一项复杂的工作。 +在未来,我们将添加更多选项以使Gitea更可配置,例如允许对仓库进行更多写访问或对同一组织中的所有仓库进行读访问。 + +## 如何避免被黑客攻击? + +有两种可能的攻击类型:未知的Runner窃取您的仓库中的代码或密钥,或恶意脚本控制您的Runner。 + +避免前者意味着不允许您不认识的人为您的仓库、组织或实例注册Runner。 + +后者要复杂一些。 +如果您为公司使用私有的Gitea实例,您可能不需要担心安全问题,因为您信任您的同事,并且可以追究他们的责任。 + +对于公共实例,情况略有不同。 +以下是我们在 [gitea.com](http://gitea.com/)上的做法: + +- 我们仅为 "gitea" 组织注册Runner,因此我们的Runner不会执行来自其他仓库的Job。 +- 我们的Runner始终在隔离容器中运行Job。虽然可以直接在主机上进行这样的操作,但出于安全考虑,我们选择不这样做。 +- 对于 fork 的拉取请求,需要获得批准才能运行Actions。参见[#22803](https://github.com/go-gitea/gitea/pull/22803)。 +- 如果有人在[gitea.com](http://gitea.com/)为其仓库或组织注册自己的Runner,我们不会反对,只是不会在我们的组织中使用它。然而,他们应该注意确保该Runner不被他们不认识的其他用户使用。 + +## act runner支持哪些操作系统? + +它在Linux、macOS和Windows上运行良好。 +虽然理论上支持其他操作系统,但需要进一步测试。 + +需要注意的一点是,如果选择直接在主机上运行Job而不是在Job容器中运行,操作系统之间的环境差异可能会导致意外的失败。 + +例如,在大多数情况下,Windows上没有可用的bash,而act尝试默认使用bash运行脚本。 +因此,您需要在工作流文件中将默认shell指定为`powershell`,参考[defaults.run](https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun)。 + +```yaml +defaults: + run: + shell: powershell +``` + +## 为什么选择GitHub Actions?为什么不选择与GitLab CI/CD兼容的工具? + +[@lunny](https://gitea.com/lunny)在实现Actions的[问题](https://github.com/go-gitea/gitea/issues/13539)中已经解释过这个问题。 +此外,Actions不仅是一个CI/CD 系统,还是一个自动化工具。 + +在开源世界中,已经有许多[市场上的Actions](https://github.com/marketplace?type=actions)实现了。 +能够重用它们是令人兴奋的。 + +## 如果它在多个标签上运行,例如 `runs-on: [label_a, label_b]`,会发生什么? + +这是有效的语法。 +它意味着它应该在具有`label_a` **和** `label_b`标签的Runner上运行,参考[GitHub Actions的工作流语法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)。 +不幸的是,act runner 并不支持这种方式。 +如上所述,我们将标签映射到环境: + +- `ubuntu` → `ubuntu:22.04` +- `centos` → `centos:8` + +但我们需要将标签组映射到环境,例如: + +- `[ubuntu]` → `ubuntu:22.04` +- `[with-gpu]` → `linux:with-gpu` +- `[ubuntu, with-gpu]` → `ubuntu:22.04_with-gpu` + +我们还需要重新设计任务分配给Runner的方式。 +具有`ubuntu`、`centos`或`with-gpu`的Runner并不一定表示它可以接受`[centos, with-gpu]`的Job。 +因此,Runner应该通知Gitea实例它只能接受具有 `[ubuntu]`、`[centos]`、`[with-gpu]` 和 `[ubuntu, with-gpu]`的Job。 +这不是一个技术问题,只是在早期设计中被忽视了。 +参见[runtime.go#L65](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65)。 + +目前,act runner尝试匹配标签中的每一个,并使用找到的第一个匹配项。 + +## 代理标签和自定义标签对于Runner有什么区别? + +![labels](/images/usage/actions/labels.png) + +代理标签是由Runner在注册过程中向Gitea实例报告的。 +而自定义标签则是由Gitea的管理员或组织或仓库的所有者手动添加的(取决于Runner所属的级别)。 + +然而,目前这方面的设计还有待改进,因为它目前存在一些不完善之处。 +您可以向已注册的Runner添加自定义标签,比如 `centos`,这意味着该Runner将接收具有`runs-on: centos`的Job。 +然而,Runner可能不知道要使用哪个环境来执行该标签,导致它使用默认镜像或导致逻辑死胡同。 +这个默认值可能与用户的期望不符。 +参见[runtime.go#L71](https://gitea.com/gitea/act_runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71)。 + +与此同时,如果您想更改Runner的标签,我们建议您重新注册Runner。 + +## Gitea Actions runner会有更多的实现吗? + +虽然我们希望提供更多的选择,但由于我们有限的人力资源,act runner将是唯一受支持的官方Runner。 +然而,无论您如何决定,Gitea 和act runner都是完全开源的,所以任何人都可以创建一个新的/更好的实现。 +我们支持您的选择,无论您如何决定。 +如果您选择分支act runner来创建自己的版本,请在您认为您的更改对其他人也有帮助的情况下贡献这些更改。 + +## Gitea 支持哪些工作流触发事件? + +表格中列出的所有事件都是支持的,并且与 GitHub 兼容。 +对于仅 GitHub 支持的事件,请参阅 GitHub 的[文档](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows)。 + +| 触发事件 | 活动类型 | +|-----------------------------|--------------------------------------------------------------------------------------------------------------------------| +| create | 不适用 | +| delete | 不适用 | +| fork | 不适用 | +| gollum | 不适用 | +| push | 不适用 | +| issues | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `milestoned`, `demilestoned`, `labeled`, `unlabeled` | +| issue_comment | `created`, `edited`, `deleted` | +| pull_request | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `synchronize`, `labeled`, `unlabeled` | +| pull_request_review | `submitted`, `edited` | +| pull_request_review_comment | `created`, `edited` | +| release | `published`, `edited` | +| registry_package | `published` | diff --git a/docs/content/usage/actions/overview.en-us.md b/docs/content/usage/actions/overview.en-us.md new file mode 100644 index 0000000000..59e539f9c1 --- /dev/null +++ b/docs/content/usage/actions/overview.en-us.md @@ -0,0 +1,51 @@ +--- +date: "2023-04-27T15:00:00+08:00" +title: "Gitea Actions" +slug: "overview" +sidebar_position: 1 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "Overview" + sidebar_position: 1 + identifier: "actions-overview" +--- + +# Gitea Actions + +Starting with Gitea **1.19**, Gitea Actions are available as a built-in CI/CD solution. + +## Name + +It is similar and compatible to [GitHub Actions](https://github.com/features/actions), and its name is inspired by it too. +To avoid confusion, we have clarified the spelling here: + +- "Gitea Actions" (with an "s", both words capitalized) is the name of the Gitea feature. +- "GitHub Actions" is the name of the GitHub feature. +- "Actions" could refer to either of the above, depending on the context. So it refers to "Gitea Actions" in this document. +- "action" or "actions" refer to some scripts/plugins to be used, like "actions/checkout@v3" or "actions/cache@v3". + +## Runners + +Just like other CI/CD solutions, Gitea doesn't run the jobs itself, but delegates the jobs to runners. +The runner of Gitea Actions is called [act runner](https://gitea.com/gitea/act_runner), it is a standalone program and also written in Go. +It is based on a [fork](https://gitea.com/gitea/act) of [nektos/act](http://github.com/nektos/act). + +Because the runner is deployed independently, there could be potential security issues. +To avoid them, please follow two simple rules: + +- Don't use a runner you don't trust for your repository, organization or instance. +- Don't provide a runner to a repository, organization or instance you don't trust. + +For Gitea instances used internally, such as instances used by enterprises or individuals, neither of these two rules is a problem, they are naturally so. +However, for public Gitea instances, such as [gitea.com](https://gitea.com), these two rules should be kept in mind when adding or using runners. + +## Status + +Gitea Actions is still under development, so there may be some bugs and missing features. +And breaking changes may be made before it's stable (v1.20 or later). + +If the situation changes, we will update it here. +So please refer to the content here when you find outdated articles elsewhere. diff --git a/docs/content/usage/actions/overview.zh-cn.md b/docs/content/usage/actions/overview.zh-cn.md new file mode 100644 index 0000000000..0e57bf568f --- /dev/null +++ b/docs/content/usage/actions/overview.zh-cn.md @@ -0,0 +1,51 @@ +--- +date: "2023-05-24T15:00:00+08:00" +title: "Gitea Actions" +slug: "overview" +sidebar_position: 1 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "Overview" + sidebar_position: 1 + identifier: "actions-overview" +--- + +# Gitea Actions + +从Gitea **1.19**版本开始,Gitea Actions成为了内置的CI/CD解决方案。 + +## 名称 + +Gitea Actions与[GitHub Actions](https://github.com/features/actions)相似且兼容,它的名称也受到了它的启发。 +为了避免混淆,在这里我们明确了拼写方式: + +- "Gitea Actions"(两个单词都大写且带有"s")是Gitea功能的名称。 +- "GitHub Actions"是GitHub功能的名称。 +- "Actions"根据上下文的不同可以指代以上任意一个。在本文档中指代的是"Gitea Actions"。 +- "action"或"actions"指代一些要使用的脚本/插件,比如"actions/checkout@v3"或"actions/cache@v3"。 + +## Runner + +和其他CI/CD解决方案一样,Gitea不会自己运行Job,而是将Job委托给Runner。 +Gitea Actions的Runner被称为[act runner](https://gitea.com/gitea/act_runner),它是一个独立的程序,也是用Go语言编写的。 +它是基于[nektos/act](http://github.com/nektos/act)的一个[分支](https://gitea.com/gitea/act) 。 + +由于Runner是独立部署的,可能存在潜在的安全问题。 +为了避免这些问题,请遵循两个简单的规则: + +- 不要为你的仓库、组织或实例使用你不信任的Runner。 +- 不要为你不信任的仓库、组织或实例提供Runner。 + +对于内部使用的Gitea实例,比如企业或个人使用的实例,这两个规则不是问题,它们自然而然就是如此。 +然而,对于公共的Gitea实例,比如[gitea.com](https://gitea.com),在添加或使用Runner时应当牢记这两个规则。 + +## 状态 + +Gitea Actions仍然在开发中,因此可能存在一些错误和缺失的功能。 +并且在稳定版本(v1.20或更高版本)之前可能会进行一些重大的更改。 + +如果情况发生变化,我们将在此处进行更新。 +因此,请在其他地方找到过时文章时参考此处的内容。 diff --git a/docs/content/usage/actions/quickstart.en-us.md b/docs/content/usage/actions/quickstart.en-us.md new file mode 100644 index 0000000000..73d90e2e68 --- /dev/null +++ b/docs/content/usage/actions/quickstart.en-us.md @@ -0,0 +1,141 @@ +--- +date: "2023-04-27T15:00:00+08:00" +title: "Quick Start" +slug: "quickstart" +sidebar_position: 10 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "Quick Start" + sidebar_position: 10 + identifier: "actions-quickstart" +--- + +# Quick Start + +This page will guide you through the process of using Gitea Actions. + +## Set up Gitea + +First of all, you need a Gitea instance. +You can follow the [documentation](installation/from-package.md) to set up a new instance or upgrade your existing one. +It doesn't matter how you install or run Gitea, as long as its version is 1.19.0 or higher. + +Actions are disabled by default, so you need to add the following to the configuration file to enable it: + +```ini +[actions] +ENABLED=true +``` + +If you want to learn more or encounter any problems while configuring it, please refer to the [Configuration Cheat Sheet](administration/config-cheat-sheet.md#actions-actions). + +### Set up runner + +Gitea Actions requires [act runner](https://gitea.com/gitea/act_runner) to run the jobs. +In order to avoid consuming too many resources and affecting the Gitea instance, it is recommended to start runners on separate machines from the Gitea instance. + +You can use the [pre-built binaries](http://dl.gitea.com/act_runner) or the [docker images](https://hub.docker.com/r/gitea/act_runner/tags) to set up the runner. + +Before proceeding any further, we suggest running it as a command line with pre-built binaries to ensure that it works with your environment, especially if you are running a runner on your local host. +And it could be easier to debug if something goes wrong. + +The runner can run the jobs in isolated Docker containers, so you need to make sure that the Docker has been installed and Docker daemon is running. +While it is not strictly necessary, because the runner can also run the jobs directly on the host, it depends on how you configure it. +However, it is recommended to use Docker to run the jobs, because it is more secure and easier to manage. + +Before running a runner, you should first register it to your Gitea instance using the following command: + +```bash +./act_runner register --no-interactive --instance <instance> --token <token> +``` + +There are two arguments required, `instance` and `token`. + +`instance` refers to the address of your Gitea instance, like `http://192.168.8.8:3000` or `https://gitea.com`. +The runner and job containers (which are started by the runner to execute jobs) will connect to this address. +This means that it could be different from the `ROOT_URL` of your Gitea instance, which is configured for web access. +It is always a bad idea to use a loopback address such as `127.0.0.1` or `localhost`. +If you are unsure which address to use, the LAN address is usually the right choice. + +`token` is used for authentication and identification, such as `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`. +It is one-time use only and cannot be used to register multiple runners. +You can obtain different levels of 'tokens' from the following places to create the corresponding level of' runners': + +- Instance level: The admin settings page, like `<your_gitea.com>/admin/actions/runners`. +- Organization level: The organization settings page, like `<your_gitea.com>/<org>/settings/actions/runners`. +- Repository level: The repository settings page, like `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`. + +![register runner](/images/usage/actions/register-runner.png) + +After registering, a new file named `.runner` will appear in the current directory. +This file stores the registration information. +Please do not edit it manually. +If this file is missing or corrupted, you can simply remove it and register again. + +Finally, it's time to start the runner: + +```bash +./act_runner daemon +``` + +And you can see the new runner in the management page: + +![view runner](/images/usage/actions/view-runner.png) + +You can find more information by visiting [Act runner](usage/actions/act-runner.md). + +### Use Actions + +Even if Actions is enabled for the Gitea instance, repositories still disable Actions by default. + +To enable it, go to the settings page of your repository like `your_gitea.com/<owner>/repo/settings` and enable `Enable Repository Actions`. + +![enable actions](/images/usage/actions/enable-actions.png) + +The next steps may be rather complicated. +You will need to study [the workflow syntax](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) for Actions and write the workflow files you want. + +However, we can just start from a simple demo: + +```yaml +name: Gitea Actions Demo +run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀 +on: [push] + +jobs: + Explore-Gitea-Actions: + runs-on: ubuntu-latest + steps: + - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event." + - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!" + - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}." + - name: Check out repository code + uses: actions/checkout@v3 + - run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner." + - run: echo "🖥️ The workflow is now ready to test your code on the runner." + - name: List files in the repository + run: | + ls ${{ gitea.workspace }} + - run: echo "🍏 This job's status is ${{ job.status }}." +``` + +You can upload it as a file with the extension `.yaml` in the directory `.gitea/workflows/` of the repository, for example `.gitea/workflows/demo.yaml`. +You might notice that this is fairly similar from the [Quickstart for GitHub Actions](https://docs.github.com/en/actions/quickstart). +That is because Gitea Actions is designed to be compatible with GitHub Actions wherever possible. + +Be careful, the demo file contains some emojis. +Please make sure your database supports them, especially when using MySQL. +If the charset is not `utf8mb4`, errors will occur, such as `Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`. +See [Database Preparation](installation/database-preparation.md#mysql) for more information. + +Alternatively, you can remove all emojis from the demo file and try again. + +The line `on: [push]` indicates that the workflow will be triggered when you push commits to this repository. +However, when you upload the YAML file, it also pushes a commit, so you should see a new task in the Actions tab. + +![view job](/images/usage/actions/view-job.png) + +Great job! You have successfully started working with Actions. diff --git a/docs/content/usage/actions/quickstart.zh-cn.md b/docs/content/usage/actions/quickstart.zh-cn.md new file mode 100644 index 0000000000..510d4a904f --- /dev/null +++ b/docs/content/usage/actions/quickstart.zh-cn.md @@ -0,0 +1,140 @@ +--- +date: "2023-05-24T15:00:00+08:00" +title: "快速入门" +slug: "quickstart" +sidebar_position: 10 +draft: false +toc: false +menu: + sidebar: + parent: "actions" + name: "快速入门" + sidebar_position: 10 + identifier: "actions-quickstart" +--- + +# 快速入门 + +本页面将指导您使用Gitea Actions的过程。 + +## 设置Gitea + +首先,您需要一个Gitea实例。 +您可以按照[文档](installation/from-package.md) 来设置一个新实例或升级现有实例。 +无论您如何安装或运行Gitea,只要版本号是1.19.0或更高即可。 + +默认情况下,Actions是禁用的,因此您需要将以下内容添加到配置文件中以启用它: + +```ini +[actions] +ENABLED=true +``` + +如果您想了解更多信息或在配置过程中遇到任何问题,请参考[配置速查表](administration/config-cheat-sheet.md#actions-actions)。 + +### 设置Runner + +Gitea Actions需要[act runner](https://gitea.com/gitea/act_runner) 来运行Job。 +为了避免消耗过多资源并影响Gitea实例,建议您在与Gitea实例分开的机器上启动Runner。 + +您可以使用[预构建的二进制文件](http://dl.gitea.com/act_runner)或[容器镜像](https://hub.docker.com/r/gitea/act_runner/tags)来设置Runner。 + +在进一步操作之前,建议您先使用预构建的二进制文件以命令行方式运行它,以确保它与您的环境兼容,尤其是如果您在本地主机上运行Runner。 +如果出现问题,这样调试起来会更容易。 + +该Runner可以在隔离的Docker容器中运行Job,因此您需要确保已安装Docker并且Docker守护进程正在运行。 +虽然这不是严格必需的,因为Runner也可以直接在主机上运行Job,这取决于您的配置方式。 +然而,建议使用Docker运行Job,因为它更安全且更易于管理。 + +在运行Runner之前,您需要使用以下命令将其注册到Gitea实例中: + +```bash +./act_runner register --no-interactive --instance <instance> --token <token> +``` + +需要两个必需的参数:`instance` 和 `token`。 + +`instance`是您的Gitea实例的地址,如`http://192.168.8.8:3000`或`https://gitea.com`。 +Runner和Job容器(由Runner启动以执行Job)将连接到此地址。 +这意味着它可能与用于Web访问的`ROOT_URL`不同。 +使用回环地址(例如 `127.0.0.1` 或 `localhost`)是一个不好的选择。 +如果不确定使用哪个地址,通常选择局域网地址即可。 + +`token` 用于身份验证和标识,例如 `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`。 +它只能使用一次,并且不能用于注册多个Runner。 +您可以从以下位置获取不同级别的`token`,从而创建出相应级别的`runner` + +- 实例级别:管理员设置页面,例如 `<your_gitea.com>/admin/actions/runners`。 +- 组织级别:组织设置页面,例如 `<your_gitea.com>/<org>/settings/actions/runners`。 +- 存储库级别:存储库设置页面,例如 `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`。 + +![register runner](/images/usage/actions/register-runner.png) + +注册后,当前目录中将出现一个名为 `.runner` 的新文件,该文件存储了注册信息。 +请不要手动编辑该文件。 +如果该文件丢失或损坏,只需删除它然后重新注册即可。 + +最后,是时候启动Runner了: + +```bash +./act_runner daemon +``` + +您可以在管理页面上看到新的Runner: + +![view runner](/images/usage/actions/view-runner.png) + +您可以通过访问[act runner](usage/actions/act-runner.md) 获取更多信息。 + +### 使用Actions + +即使对于启用了Gitea实例的Actions,存储库仍默认禁用Actions。 + +要启用它,请转到存储库的设置页面,例如`your_gitea.com/<owner>/repo/settings`,然后启用`Enable Repository Actions`。 + +![enable actions](/images/usage/actions/enable-actions.png) + +接下来的步骤可能相当复杂。 +您需要学习Actions的[工作流语法](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions),并编写您想要的工作流文件。 + +不过,我们可以从一个简单的演示开始: + +```yaml +name: Gitea Actions Demo +run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀 +on: [push] + +jobs: + Explore-Gitea-Actions: + runs-on: ubuntu-latest + steps: + - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event." + - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!" + - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}." + - name: Check out repository code + uses: actions/checkout@v3 + - run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner." + - run: echo "🖥️ The workflow is now ready to test your code on the runner." + - name: List files in the repository + run: | + ls ${{ gitea.workspace }} + - run: echo "🍏 This job's status is ${{ job.status }}." +``` + +您可以将上述示例上传为一个以`.yaml`扩展名的文件,放在存储库的`.gitea/workflows/`目录中,例如`.gitea/workflows/demo.yaml`。 +您可能会注意到,这与[GitHub Actions的快速入门](https://docs.github.com/en/actions/quickstart)非常相似。 +这是因为Gitea Actions在尽可能兼容GitHub Actions的基础上进行设计。 + +请注意,演示文件中包含一些表情符号。 +请确保您的数据库支持它们,特别是在使用MySQL时。 +如果字符集不是`utf8mb4,将出现错误,例如`Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`。 +有关更多信息,请参阅[数据库准备工作](installation/database-preparation.md#mysql)。 + +或者,您可以从演示文件中删除所有表情符号,然后再尝试一次。 + +`on: [push]` 这一行表示当您向该存储库推送提交时,工作流将被触发。 +然而,当您上传 YAML 文件时,它也会推送一个提交,所以您应该在"Actions"标签中看到一个新的任务。 + +![view job](/images/usage/actions/view-job.png) + +做得好!您已成功开始使用Actions。 |