0
0
Fork 0
mirror of https://github.com/go-gitea/gitea synced 2024-11-06 06:09:07 +01:00

Add Chinese documentations for Actions (#24902)

This commit is contained in:
HesterG 2023-05-25 13:52:12 +08:00 committed by GitHub
parent 69eb92a6e1
commit cff4e37d43
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
12 changed files with 877 additions and 6 deletions

View file

@ -1,7 +1,7 @@
--- ---
date: "2023-04-27T15:00:00+08:00" date: "2023-04-27T15:00:00+08:00"
title: "Act Runner" title: "Act Runner"
slug: "usage/actions/act-runner" slug: "act-runner"
weight: 20 weight: 20
draft: false draft: false
toc: false toc: false

View file

@ -0,0 +1,203 @@
---
date: "2023-05-24T15:00:00+08:00"
title: "Act Runner"
slug: "act-runner"
weight: 20
draft: false
toc: false
menu:
sidebar:
parent: "actions"
name: "Act Runner"
weight: 20
identifier: "actions-runner"
---
# Act Runner
本页面将详细介绍[Act Runner](https://gitea.com/gitea/act_runner)这是Gitea Actions的Runner。
**目录**
{{< toc >}}
## 要求
建议在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镜像时可以使用`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/runners`
- 组织级别:组织设置页面,例如 `<your_gitea.com>/<org>/settings/runners`
- 存储库级别:存储库设置页面,例如 `<your_gitea.com>/<owner>/<repo>/settings/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的容器而不是主机机器本身。
### 标签
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仍处于开发中建议定期检查最新版本并进行升级。

View file

@ -1,7 +1,7 @@
--- ---
date: "2023-04-27T15:00:00+08:00" date: "2023-04-27T15:00:00+08:00"
title: "Compared to GitHub Actions" title: "Compared to GitHub Actions"
slug: "usage/actions/comparison" slug: "comparison"
weight: 30 weight: 30
draft: false draft: false
toc: false toc: false

View file

@ -0,0 +1,171 @@
---
date: "2023-05-24T15:00:00+08:00"
title: "与GitHub Actions的对比"
slug: "comparison"
weight: 30
draft: false
toc: false
menu:
sidebar:
parent: "actions"
name: "对比"
weight: 30
identifier: "actions-comparison"
---
# 与GitHub Actions的对比
尽管Gitea Actions旨在与GitHub Actions兼容但它们之间存在一些差异。
**目录**
{{< toc >}}
## 额外功能
### 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.io/2023/04/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`进行配置。请参阅[配置备忘单]({{< relref "doc/administration/config-cheat-sheet.en-us.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:
...
```

View file

@ -1,7 +1,7 @@
--- ---
date: "2023-04-27T15:00:00+08:00" date: "2023-04-27T15:00:00+08:00"
title: "Design of Gitea Actions" title: "Design of Gitea Actions"
slug: "usage/actions/design" slug: "design"
weight: 40 weight: 40
draft: false draft: false
toc: false toc: false

View file

@ -0,0 +1,136 @@
---
date: "2023-05-24T15:00:00+08:00"
title: "Gitea Actions设计"
slug: "design"
weight: 40
draft: false
toc: false
menu:
sidebar:
parent: "actions"
name: "设计"
weight: 40
identifier: "actions-design"
---
# Gitea Actions设计
Gitea Actions由多个组件组成。本文档将对它们进行逐个描述。
**目录**
{{< toc >}}
## 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)
图片中标记了四个网络连接,并且箭头的方向表示建立连接的方向。
### 连接 1act runner到Gitea实例
act runner 必须能够连接到Gitea以接收任务并发送执行结果回来。
### 连接 2Job容器到Gitea实例
即使Job容器位于同一台机器上它们的网络命名空间与Runner不同。
举个例子,如果工作流中包含 `actions/checkout@v3`Job容器需要连接到Gitea来获取代码。
获取代码并不总是运行某些Job所必需的但在大多数情况下是必需的。
如果您使用回环地址注册Runner当Runner与Gitea在同一台机器上时Runner可以连接到Gitea。
然而如果Job容器尝试从本地主机获取代码它将失败因为Gitea不在同一个容器中。
### 连接 3act 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镜像注册表。
### 连接 4Job容器到互联网
当使用诸如`actions/setup-go@v4`的Actions时可能需要从互联网下载资源以设置Job容器中的Go语言环境。
因此成功完成这些Actions需要访问互联网。
然而,这也是可选的。
您可以使用自定义的Actions来避免依赖互联网访问或者可以使用已安装所有依赖项的打包的Docker镜像来运行Job。
## 总结
使用Gitea Actions只需要确保Runner能够连接到Gitea实例。
互联网访问是可选的,但如果没有互联网访问,将需要额外的工作。
换句话说当Runner能够自行查询互联网时它的工作效果最好但您不需要将其暴露给互联网无论是单向还是双向
如果您在使用Gitea Actions时遇到任何网络问题希望上面的图片能够帮助您进行故障排除。

View file

@ -1,7 +1,7 @@
--- ---
date: "2023-04-27T15:00:00+08:00" date: "2023-04-27T15:00:00+08:00"
title: "Frequently Asked Questions of Gitea Actions" title: "Frequently Asked Questions of Gitea Actions"
slug: "usage/actions/faq" slug: "faq"
weight: 100 weight: 100
draft: false draft: false
toc: false toc: false

View file

@ -0,0 +1,166 @@
---
date: "2023-05-24T15:00:00+08:00"
title: "Gitea Actions常见问题解答"
slug: "faq"
weight: 100
draft: false
toc: false
menu:
sidebar:
parent: "actions"
name: "常见问题"
weight: 100
identifier: "actions-faq"
---
# Gitea Actions常见问题解答
本页面包含一些关于Gitea Actions的常见问题和答案。
**目录**
{{< toc >}}
## 为什么默认情况下不启用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来创建自己的版本请在您认为您的更改对其他人也有帮助的情况下贡献这些更改。

View file

@ -1,7 +1,7 @@
--- ---
date: "2023-04-27T15:00:00+08:00" date: "2023-04-27T15:00:00+08:00"
title: "Gitea Actions" title: "Gitea Actions"
slug: "usage/actions/overview" slug: "overview"
weight: 1 weight: 1
draft: false draft: false
toc: false toc: false

View file

@ -0,0 +1,55 @@
---
date: "2023-05-24T15:00:00+08:00"
title: "Gitea Actions"
slug: "overview"
weight: 1
draft: false
toc: false
menu:
sidebar:
parent: "actions"
name: "Overview"
weight: 1
identifier: "actions-overview"
---
# Gitea Actions
从Gitea **1.19**版本开始Gitea Actions成为了内置的CI/CD解决方案。
**目录**
{{< toc >}}
## 名称
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或更高版本)之前可能会进行一些重大的更改。
如果情况发生变化,我们将在此处进行更新。
因此,请在其他地方找到过时文章时参考此处的内容。

View file

@ -1,7 +1,7 @@
--- ---
date: "2023-04-27T15:00:00+08:00" date: "2023-04-27T15:00:00+08:00"
title: "Quick Start" title: "Quick Start"
slug: "usage/actions/quickstart" slug: "quickstart"
weight: 10 weight: 10
draft: false draft: false
toc: false toc: false

View file

@ -0,0 +1,140 @@
---
date: "2023-05-24T15:00:00+08:00"
title: "快速入门"
slug: "quickstart"
weight: 10
draft: false
toc: false
menu:
sidebar:
parent: "actions"
name: "快速入门"
weight: 10
identifier: "actions-quickstart"
---
# 快速入门
本页面将指导您使用Gitea Actions的过程。
**目录**
{{< toc >}}
## 设置Gitea
首先您需要一个Gitea实例。
您可以按照[文档]({{< relref "doc/installation/from-package.en-us.md" >}}) 来设置一个新实例或升级现有实例。
无论您如何安装或运行Gitea只要版本号是1.19.0或更高即可。
默认情况下Actions是禁用的因此您需要将以下内容添加到配置文件中以启用它
```ini
[actions]
ENABLED=true
```
如果您想了解更多信息或在配置过程中遇到任何问题,请参考[配置速查表]({{< relref "doc/administration/config-cheat-sheet.en-us.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。
您可以从 `<your_gitea.com>/admin/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]({{< relref "doc/usage/actions/act-runner.zh-cn.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`。
有关更多信息,请参阅[数据库准备工作]({{< relref "doc/installation/database-preparation.en-us.md#mysql" >}})。
或者,您可以从演示文件中删除所有表情符号,然后再尝试一次。
`on: [push]` 这一行表示当您向该存储库推送提交时,工作流将被触发。
然而,当您上传 YAML 文件时,它也会推送一个提交,所以您应该在"Actions"标签中看到一个新的任务。
![view job](/images/usage/actions/view-job.png)
做得好您已成功开始使用Actions。