rename act runner to runner (#390)

Depends on gitea/runner#850

---------

Co-authored-by: Nicolas <[email protected]>
Co-authored-by: silverwind <[email protected]>
Reviewed-on: https://gitea.com/gitea/docs/pulls/390
Reviewed-by: techknowlogick <[email protected]>
Reviewed-by: silverwind <[email protected]>
Reviewed-by: Nicolas <[email protected]>

i18n/zh-cn/docusaurus-plugin-content-docs/current/usage/actions/design.md

@@ -8,35 +8,11 @@ sidebar_position: 40
 
 Gitea Actions由多个组件组成。本文档将对它们进行逐个描述。
 
-## Act
+## Gitea Runner
 
-[nektos/act](https://github.com/nektos/act) 项目是一个优秀的工具，允许你在本地运行GitHub Actions。
-我们受到了它的启发，并思考它是否可能为Gitea运行Actions。
+Gitea Runner部分基于[nektos/act](https://github.com/nektos/act)的硬分支。
 
-然而，尽管[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不同的服务器上运行。
+与其他CI Runner一样，我们将其设计为Gitea的外部部分，这意味着它应该在与Gitea不同的服务器上运行。
 
 为了确保Runner连接到正确的Gitea实例，我们需要使用令牌注册它。
 此外，Runner通过声明自己的标签向Gitea报告它可以运行的Job类型。
@@ -47,7 +23,7 @@ Gitea的Runner被称为act runner，因为它基于act。
 这意味着Runner可以接受需要在`my_custom_label`上运行的Job，并通过使用`centos:7`镜像的Docker容器来运行它。
 
 然而，Docker不是唯一的选择。
-act 也支持直接在主机上运行Job。
+Runner 也支持直接在主机上运行Job。
 这是通过像`linux_arm:host`这样的标签实现的。
 这个标签表示Runner可以接受需要在`linux_arm`上运行的Job，并直接在主机上运行它们。
 
@@ -63,7 +39,7 @@ act 也支持直接在主机上运行Job。
 
 ## 通信协议
 
-由于act runner是Gitea的独立部分，我们需要一种协议让Runner与Gitea实例进行通信。
+由于 runner 是 Gitea 的独立部分，我们需要一种协议让 Runner 与 Gitea 实例进行通信。
 然而，我们不认为让Gitea监听一个新端口是个好主意。
 相反，我们希望重用HTTP端口，这意味着我们需要一个与HTTP兼容的协议。
 因此，我们选择使用基于HTTP的gRPC。
@@ -74,17 +50,17 @@ act 也支持直接在主机上运行Job。
 ## 网络架构
 
 让我们来看一下整体的网络架构。
-这将帮助您解决一些问题，并解释为什么使用回环地址注册Runner是个不好的主意。
+这将帮助您解决一些问题，并解释为什么使用回环地址注册 Runner 是个不好的主意。
 
 ![network](/images/usage/actions/network.png)
 
 图片中标记了四个网络连接，并且箭头的方向表示建立连接的方向。
 
-### 连接 1，act runner到Gitea实例
+### 连接 1，runner 到 Gitea 实例
 
-act runner 必须能够连接到Gitea以接收任务并发送执行结果回来。
+Runner 必须能够连接到Gitea以接收任务并发送执行结果回来。
 
-### 连接 2，Job容器到Gitea实例
+### 连接 2，Job 容器到 Gitea 实例
 
 即使Job容器位于同一台机器上，它们的网络命名空间与Runner不同。
 举个例子，如果工作流中包含 `actions/checkout@v4`，Job容器需要连接到Gitea来获取代码。
@@ -93,9 +69,9 @@ act runner 必须能够连接到Gitea以接收任务并发送执行结果回来
 如果您使用回环地址注册Runner，当Runner与Gitea在同一台机器上时，Runner可以连接到Gitea。
 然而，如果Job容器尝试从本地主机获取代码，它将失败，因为Gitea不在同一个容器中。
 
-### 连接 3，act runner到互联网
+### 连接 3，runner 到互联网
 
-当您使用诸如 `actions/checkout@v4` 的一些Actions时，act runner下载的是脚本，而不是Job容器。
+当您使用诸如 `actions/checkout@v4` 的一些Actions时， runner下载的是脚本，而不是Job容器。
 默认情况下，它从[github.com](http://github.com/)下载，因此需要访问互联网。如果您设置的是 self，
 那么默认将从您的当前Gitea实例下载，那么此步骤不需要连接到互联网。
 它还默认从Docker Hub下载一些Docker镜像，这也需要互联网访问。