mirror of
https://gitea.com/gitea/docs.git
synced 2026-11-08 02:50:31 +00:00
Add version v28 (#564)
<!-- cloudflare-preview --> Preview: https://pr-564.docs-gitea-com.pages.dev Reviewed-on: https://gitea.com/gitea/docs/pulls/564 Reviewed-by: bircni <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
This commit is contained in:
Lunny Xiao authored and 
bircni committed
1 parent
deb2f068d4
commit
ba60edbbda
338 files changed
+114457
-47
No files matched your search
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"label": "工作流",
|
||||
"position": 30,
|
||||
"link": {
|
||||
"type": "generated-index",
|
||||
"slug": "/usage/actions",
|
||||
"description": "自动化工作流，CI/CD 和操作功能"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "comparison"
|
||||
sidebar_position: 15
|
||||
---
|
||||
|
||||
# 与GitHub Actions的对比
|
||||
|
||||
Gitea Actions旨在与GitHub Actions兼容，差异如下。
|
||||
|
||||
## 额外功能
|
||||
|
||||
<a id="absolute-action-urls"></a>
|
||||
### Action URL绝对路径
|
||||
|
||||
`uses:`支持指向任意Git托管平台的绝对URL，例如`uses: https://gitea.com/actions/checkout@v4`。
|
||||
|
||||
<a id="action-prefixes"></a>
|
||||
### Action前缀
|
||||
|
||||
`uses:`支持以下前缀：
|
||||
|
||||
- `self:`引用您自己的Gitea实例，例如`uses: self:owner/repo@v1`或`uses: self:owner/repo/.gitea/workflows/build.yml@v1`
|
||||
- `builtin:`运行Gitea Runner内置的Action，无需下载，Job镜像中也无需Node，例如`uses: builtin:checkout`
|
||||
|
||||
`builtin:checkout`支持`actions/checkout`的`repository`、`ref`、`token`、`path`和`fetch-depth`输入，默认值相同，其他输入会使步骤失败。
|
||||
|
||||
<a id="workflow-relative-actions"></a>
|
||||
### 相对于工作流的Actions
|
||||
|
||||
`$/`引用工作流所在的仓库和提交，或外层复合Action所在的仓库和提交，例如`uses: $/.gitea/actions/build`。
|
||||
与`./`不同，它无需事先检出代码。
|
||||
|
||||
### 使用Go编写Actions
|
||||
|
||||
请参阅[创建Go Actions](https://blog.gitea.com/creating-go-actions/)。
|
||||
|
||||
### 支持非标准的调度语法 @yearly, @monthly, @weekly, @daily, @hourly
|
||||
|
||||
`schedule`还支持`@yearly`、`@monthly`、`@weekly`、`@daily`和`@hourly`，而[GitHub不支持](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule)。
|
||||
|
||||
## 不支持的工作流语法
|
||||
|
||||
### `jobs.<job_id>.environment`
|
||||
|
||||
[`jobs.<job_id>.environment`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment)会被忽略。
|
||||
|
||||
### 复杂的`runs-on`
|
||||
|
||||
[`runs-on`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)支持：
|
||||
|
||||
- 静态字符串：`runs-on: self-hosted`
|
||||
- 标签数组：`runs-on: [linux, self-hosted]`
|
||||
- 字符串表达式：`runs-on: ${{ github.event_name == 'push' && 'ubuntu-latest' || 'self-hosted' }}`
|
||||
- 包含表达式的数组：`runs-on: [linux, "${{ github.event_name == 'push' && 'ubuntu-latest' || 'self-hosted' }}"]`
|
||||
|
||||
## 缺失的功能
|
||||
|
||||
### 软件包仓库授权
|
||||
|
||||
`GITEA_TOKEN`无法发布到其所属仓库的软件包注册表，例如无法推送OCI镜像。
|
||||
请改用个人访问令牌，参见[此问题](https://github.com/go-gitea/gitea/issues/23642#issuecomment-2119876692)。
|
||||
|
||||
### 问题匹配器
|
||||
|
||||
[问题匹配器](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md)会被忽略。
|
||||
|
||||
### 为错误创建注释
|
||||
|
||||
[错误注释](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error)会被忽略。
|
||||
|
||||
### 表达式
|
||||
|
||||
[表达式](https://docs.github.com/en/actions/learn-github-actions/expressions)支持GitHub的标准函数和上下文。
|
||||
|
||||
## 缺失的UI功能
|
||||
|
||||
### 预处理和后处理步骤
|
||||
|
||||
预处理和后处理步骤在Job日志中没有单独的区块。
|
||||
|
||||
### 服务步骤
|
||||
|
||||
服务步骤在Job日志中没有单独的区块。
|
||||
|
||||
## 不一样的行为
|
||||
|
||||
### `permissions`和`jobs.<job_id>.permissions`
|
||||
|
||||
`permissions`和`jobs.<job_id>.permissions`控制`GITEA_TOKEN`的权限，该权限受仓库和所有者设置的限制，并在fork拉取请求和跨仓库访问时受到进一步限制。
|
||||
不支持`statuses`、`checks`、`deployments`、`id-token`、`security-events`和`pages`等GitHub专有的权限范围，而Gitea额外提供了`code`、`releases`、`wiki`和`projects`。
|
||||
请参阅[Actions Job令牌权限](token-permissions.md)。
|
||||
|
||||
### 下载Actions
|
||||
|
||||
未指定主机的Actions（如`uses: actions/checkout@v4`）会从`https://github.com`下载，当`[actions].DEFAULT_ACTIONS_URL`为`self`时则从您自己的实例下载。
|
||||
请参阅[配置备忘单](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
其他来源请参阅[Action URL绝对路径](#absolute-action-urls)、[Action前缀](#action-prefixes)和[相对于工作流的Actions](#workflow-relative-actions)。
|
||||
|
||||
### 上下文可用性
|
||||
|
||||
不检查[上下文可用性](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability)，因此`env`等上下文可以在更多地方使用。
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "design"
|
||||
sidebar_position: 40
|
||||
---
|
||||
|
||||
# Gitea Actions设计
|
||||
|
||||
Gitea Actions由多个组件组成。本文档将对它们进行逐个描述。
|
||||
|
||||
## Gitea Runner
|
||||
|
||||
Gitea Runner部分基于[nektos/act](https://github.com/nektos/act)的硬分支。
|
||||
|
||||
与其他CI Runner一样，我们将其设计为Gitea的外部部分，这意味着它应该在与Gitea不同的服务器上运行。
|
||||
|
||||
为了确保Runner连接到正确的Gitea实例，我们需要使用令牌注册它。
|
||||
此外，Runner通过声明自己的标签向Gitea报告它可以运行的Job类型。
|
||||
|
||||
之前，我们提到工作流文件中的 `runs-on: ubuntu-latest` 表示该Job将在具有`ubuntu-latest`标签的Runner上运行。
|
||||
但是，Runner如何知道要运行 `ubuntu-latest`？答案在于将标签映射到环境。
|
||||
这就是为什么Runner的每个标签都会指定一个环境，比如`my_custom_label:docker://centos:7`。
|
||||
这意味着Runner可以接受需要在`my_custom_label`上运行的Job，并通过使用`centos:7`镜像的Docker容器来运行它。
|
||||
|
||||
然而，Docker不是唯一的选择。
|
||||
Runner 也支持直接在主机上运行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`。
|
||||
|
||||
## 通信协议
|
||||
|
||||
由于 runner 是 Gitea 的独立部分，我们需要一种协议让 Runner 与 Gitea 实例进行通信。
|
||||
然而，我们不认为让Gitea监听一个新端口是个好主意。
|
||||
相反，我们希望重用HTTP端口，这意味着我们需要一个与HTTP兼容的协议。
|
||||
因此，我们选择使用基于HTTP的gRPC。
|
||||
|
||||
该协议定义在[actions-proto-def](https://gitea.com/gitea/actions-proto-def)中，其Go代码位于[actionslib](https://gitea.com/gitea/actionslib)。
|
||||
有关 gRPC 的更多信息，请访问[其官方网站](https://grpc.io/)。
|
||||
|
||||
## 网络架构
|
||||
|
||||
让我们来看一下整体的网络架构。
|
||||
这将帮助您解决一些问题，并解释为什么使用回环地址注册 Runner 是个不好的主意。
|
||||
|
||||
|
||||
|
||||
图片中标记了四个网络连接，并且箭头的方向表示建立连接的方向。
|
||||
|
||||
### 连接 1，runner 到 Gitea 实例
|
||||
|
||||
Runner 必须能够连接到Gitea以接收任务并发送执行结果回来。
|
||||
|
||||
### 连接 2，Job 容器到 Gitea 实例
|
||||
|
||||
即使Job容器位于同一台机器上，它们的网络命名空间与Runner不同。
|
||||
举个例子，如果工作流中包含 `actions/checkout@v4`，Job容器需要连接到Gitea来获取代码。
|
||||
获取代码并不总是运行某些Job所必需的，但在大多数情况下是必需的。
|
||||
|
||||
如果您使用回环地址注册Runner，当Runner与Gitea在同一台机器上时，Runner可以连接到Gitea。
|
||||
然而，如果Job容器尝试从本地主机获取代码，它将失败，因为Gitea不在同一个容器中。
|
||||
|
||||
### 连接 3，runner 到互联网
|
||||
|
||||
当您使用诸如 `actions/checkout@v4` 的一些Actions时， runner下载的是脚本，而不是Job容器。
|
||||
默认情况下，它从[github.com](https://github.com/)下载这些脚本，这需要访问互联网。
|
||||
如果将`DEFAULT_ACTIONS_URL`设置为`self`，或使用`uses: self:owner/repo@ref`，它会改为从您的Gitea实例下载。
|
||||
它还默认从Docker Hub下载一些Docker镜像，这也需要互联网访问。
|
||||
|
||||
然而，互联网访问并不是绝对必需的。
|
||||
您可以配置您的Gitea实例从您的内部网络设施中获取 Actions 或镜像。
|
||||
|
||||
实际上，您的Gitea实例可以同时充当 Actions 市场和镜像注册表。
|
||||
您可以将GitHub上的Actions仓库镜像到您的Gitea实例，并将其用作普通Actions。
|
||||
而 [Gitea 容器注册表](usage/packages/container.md) 可用作Docker镜像注册表。
|
||||
|
||||
### 连接 4，Job容器到互联网
|
||||
|
||||
当使用诸如`actions/setup-go@v5`的Actions时，可能需要从互联网下载资源，以设置Job容器中的Go语言环境。
|
||||
因此，成功完成这些Actions需要访问互联网。
|
||||
|
||||
然而，这也是可选的。
|
||||
您可以使用自定义的Actions来避免依赖互联网访问，或者可以使用已安装所有依赖项的打包的Docker镜像来运行Job。
|
||||
|
||||
## 总结
|
||||
|
||||
使用Gitea Actions只需要确保Runner能够连接到Gitea实例。
|
||||
互联网访问是可选的，但如果没有互联网访问，将需要额外的工作。
|
||||
换句话说：当Runner能够自行查询互联网时，它的工作效果最好，但您不需要将其暴露给互联网（无论是单向还是双向）。
|
||||
|
||||
如果您在使用Gitea Actions时遇到任何网络问题，希望上面的图片能够帮助您进行故障排除。
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "faq"
|
||||
sidebar_position: 100
|
||||
---
|
||||
|
||||
# Gitea Actions常见问题解答
|
||||
|
||||
本页面包含一些关于Gitea Actions的常见问题和答案。
|
||||
|
||||
## 是否可以在我的实例中默认禁用新仓库的Actions？
|
||||
|
||||
是的，当您为实例启用Actions时，您可以选择默认启用actions单元以适用于所有新仓库。
|
||||
|
||||
```ini
|
||||
[repository]
|
||||
; 去掉 repo.actions 将不会为新仓库自动启用actions
|
||||
DEFAULT_REPO_UNITS = ...,repo.actions
|
||||
```
|
||||
|
||||
## 在工作流文件中应该使用`${{ github.xyz }}`还是`${{ gitea.xyz }}`？
|
||||
|
||||
您可以使用`github.xyz`，Gitea将正常工作。
|
||||
如前所述，Gitea Actions的设计是与GitHub Actions兼容的。
|
||||
然而，我们建议在工作流文件中使用`gitea.xyz`，以防止在工作流文件中出现不同类型的密钥（因为您在Gitea上使用此工作流，而不是GitHub）。
|
||||
不过，这完全是可选的，因为目前这两个选项的效果是相同的。
|
||||
|
||||
## 使用`actions/checkout@v4`等Actions时，Job容器会从何处下载脚本？
|
||||
|
||||
默认从`https://github.com`下载，当`[actions].DEFAULT_ACTIONS_URL`为`self`时则从您自己的实例下载，参见[配置速查表](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
|
||||
要使用其他位置的Action，请指明其主机：
|
||||
|
||||
- `uses: https://gitea.com/owner/repo@ref`
|
||||
- `uses: http://your_gitea_instance.com/owner/repo@ref`
|
||||
- `uses: self:owner/repo@ref`，用于您自己的Gitea实例
|
||||
|
||||
## 如何限制Runner的权限？
|
||||
|
||||
Runner仅连接到您的Gitea实例。
|
||||
对于每个Job，Runner会获得一个仅限于该Job所属仓库的`GITEA_TOKEN`，参见[Actions Job令牌权限](token-permissions.md)。
|
||||
如需让Job访问更多私有仓库或外部系统，请向其传递[密钥](usage/actions/secrets.md)。
|
||||
|
||||
## 如何避免被黑客攻击？
|
||||
|
||||
有两种可能的攻击类型：未知的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不被他们不认识的其他用户使用。
|
||||
|
||||
## Runner 支持哪些操作系统？
|
||||
|
||||
官方发布了Linux、macOS和Windows的二进制文件。
|
||||
理论上，Go和Docker支持的其他系统也可以运行。
|
||||
|
||||
## 为什么选择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]`，会发生什么？
|
||||
|
||||
该Job会在拥有所有这些标签的Runner上运行，与[GitHub](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on)一致。
|
||||
Runner会使用这些标签中它所拥有的第一个标签对应的环境。
|
||||
|
||||
## 代理标签和自定义标签对于Runner有什么区别？
|
||||
|
||||
Gitea已不再有自定义标签。
|
||||
Runner每次启动时都会声明其标签，标签来自`runner.labels`配置或注册时指定的标签，因此请在那里修改并重启Runner。
|
||||
|
||||
## Gitea Actions runner会有更多的实现吗？
|
||||
|
||||
虽然我们希望提供更多的选择，但由于我们有限的人力资源，runner 将是唯一受支持的官方 Runner。
|
||||
然而，无论您如何决定，Gitea 和 runner都是完全开源的，所以任何人都可以创建一个新的/更好的实现。
|
||||
我们支持您的选择，无论您如何决定。
|
||||
如果您选择分支 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` |
|
||||
|
||||
> 对于 `pull_request` 事件，在 [GitHub Actions](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) 中 `ref` 是 `refs/pull/:prNumber/merge`，它指向这个拉取请求合并提交的一个预览。但是 Gitea 没有这种 reference。
|
||||
> 因此，Gitea Actions 中 `ref` 是 `refs/pull/:prNumber/head`，它指向这个拉取请求的头分支而不是合并提交的预览。
|
||||
|
||||
## 如何共享私有仓库中的Actions和可复用工作流？
|
||||
|
||||
前往仓库的**设置** > **Actions** > **常规**页面并添加协作所有者。
|
||||
协作所有者的私有仓库可以访问当前仓库中的Actions和工作流。
|
||||
|
||||
如需在同一用户或组织内共享，请改为在该用户或组织的**设置** > **Actions** > **常规** > **跨仓库访问**中添加这些私有仓库。
|
||||
参见[跨仓库访问](token-permissions.md#cross-repository-access)。
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "overview"
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
# Overview
|
||||
|
||||
从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@v4"或"actions/cache@v3"。
|
||||
|
||||
## Runner
|
||||
|
||||
和其他CI/CD解决方案一样，Gitea不会自己运行Job，而是将Job委托给Runner。
|
||||
Gitea Actions的Runner被称为[Gitea Runner](https://gitea.com/gitea/runner)，它是一个独立的程序，也是用Go语言编写的。
|
||||
它的重要部分来自[nektos/act](http://github.com/nektos/act)的一个硬分支。
|
||||
|
||||
由于Runner是独立部署的，可能存在潜在的安全问题。
|
||||
为了避免这些问题，请遵循两个简单的规则：
|
||||
|
||||
- 不要为你的仓库、组织或实例使用你不信任的Runner。
|
||||
- 不要为你不信任的仓库、组织或实例提供Runner。
|
||||
|
||||
对于内部使用的Gitea实例，比如企业或个人使用的实例，这两个规则不是问题，它们自然而然就是如此。
|
||||
然而，对于公共的Gitea实例，比如[gitea.com](https://gitea.com)，在添加或使用Runner时应当牢记这两个规则。
|
||||
|
||||
## 状态
|
||||
|
||||
Gitea Actions仍然在开发中，因此可能存在一些错误和缺失的功能。
|
||||
并且在稳定版本（v1.20或更高版本）之前可能会进行一些重大的更改。
|
||||
|
||||
如果情况发生变化，我们将在此处进行更新。
|
||||
因此，请在其他地方找到过时文章时参考此处的内容。
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "quickstart"
|
||||
sidebar_position: 10
|
||||
---
|
||||
|
||||
# 快速入门
|
||||
|
||||
本页面将指导您使用Gitea Actions的过程。
|
||||
|
||||
## 设置Gitea
|
||||
|
||||
首先，您需要一个Gitea实例。
|
||||
您可以按照[文档](installation/from-package.md) 来设置一个新实例或升级现有实例。
|
||||
无论您如何安装或运行Gitea，只要版本号是1.19.0或更高即可。
|
||||
|
||||
从1.21.0开始，默认情况下，Actions是启用的。如果您正在使用1.21.0之前的版本，您需要将以下内容添加到配置文件中以启用它：
|
||||
|
||||
```ini
|
||||
[actions]
|
||||
ENABLED=true
|
||||
```
|
||||
|
||||
如果您想了解更多信息或在配置过程中遇到任何问题，请参考[配置速查表](../../administration/config-cheat-sheet.md#actions-actions)。
|
||||
|
||||
### 设置Runner
|
||||
|
||||
Gitea Actions需要[runner](https://gitea.com/gitea/runner) 来运行Job。
|
||||
为了避免消耗过多资源并影响Gitea实例，建议您在与Gitea实例分开的机器上启动Runner。
|
||||
|
||||
您可以使用[预构建的二进制文件](http://dl.gitea.com/gitea-runner)或[容器镜像](https://hub.docker.com/r/gitea/runner/tags)来设置Runner。
|
||||
|
||||
在进一步操作之前，建议您先使用预构建的二进制文件以命令行方式运行它，以确保它与您的环境兼容，尤其是如果您在本地主机上运行Runner。
|
||||
如果出现问题，这样调试起来会更容易。
|
||||
|
||||
该Runner可以在隔离的Docker容器中运行Job，因此您需要确保已安装Docker并且Docker守护进程正在运行。
|
||||
虽然这不是严格必需的，因为Runner也可以直接在主机上运行Job，这取决于您的配置方式。
|
||||
然而，建议使用Docker运行Job，因为它更安全且更易于管理。
|
||||
|
||||
在运行Runner之前，您需要使用以下命令将其注册到Gitea实例中：
|
||||
|
||||
```bash
|
||||
./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`。
|
||||
|
||||
|
||||
|
||||
注册后，当前目录中将出现一个名为 `.runner` 的新文件，该文件存储了注册信息。
|
||||
请不要手动编辑该文件。
|
||||
如果该文件丢失或损坏，只需删除它然后重新注册即可。
|
||||
|
||||
最后，是时候启动Runner了：
|
||||
|
||||
```bash
|
||||
./runner daemon
|
||||
```
|
||||
|
||||
您可以在管理页面上看到新的Runner：
|
||||
|
||||
|
||||
|
||||
您可以通过访问[Gitea Runner](runner) 获取更多信息。
|
||||
|
||||
### 使用Actions
|
||||
|
||||
即使对于启用了Gitea实例的Actions，存储库仍默认禁用Actions。
|
||||
|
||||
要启用它，请转到存储库的设置页面，例如`your_gitea.com/<owner>/repo/settings`，然后启用`Enable Repository Actions`。
|
||||
|
||||
|
||||
|
||||
接下来的步骤可能相当复杂。
|
||||
您需要学习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@v4
|
||||
- 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#mysqlmariadb)。
|
||||
|
||||
或者，您可以从演示文件中删除所有表情符号，然后再尝试一次。
|
||||
|
||||
`on: [push]` 这一行表示当您向该存储库推送提交时，工作流将被触发。
|
||||
然而，当您上传 YAML 文件时，它也会推送一个提交，所以您应该在"Actions"标签中看到一个新的任务。
|
||||
|
||||
|
||||
|
||||
做得好！您已成功开始使用Actions。
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
date: "2023-05-24T15:00:00+08:00"
|
||||
slug: "runner"
|
||||
sidebar_position: 20
|
||||
aliases:
|
||||
- /zh-cn/act-runner
|
||||
---
|
||||
|
||||
# Runner
|
||||
|
||||
本页面将介绍[Gitea Runner](https://gitea.com/gitea/runner)，这是Gitea Actions的Runner。
|
||||
|
||||
:::tip
|
||||
详细的安装、配置和使用说明，请参阅 [Gitea Runner 文档](/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`。
|
||||
|
||||
注册令牌也可以通过 Gitea 的 [命令行](../../administration/command-line.md#actions-generate-runner-token) 获得:
|
||||
|
||||
```
|
||||
gitea --config /etc/gitea/app.ini actions generate-runner-token
|
||||
```
|
||||
|
||||
用户也可以使用 `GITEA_RUNNER_REGISTRATION_TOKEN` 或 `GITEA_RUNNER_REGISTRATION_TOKEN_FILE` 环境变量以在 Gitea 启动时设置全局的注册令牌，例如：
|
||||
|
||||
```
|
||||
openssl rand -hex 24 > /some-dir/runner-token
|
||||
export GITEA_RUNNER_REGISTRATION_TOKEN_FILE=/some-dir/runner-token
|
||||
./gitea --config ...
|
||||
```
|
||||
|
||||
来自环境变量的令牌在通过 Web 界面或 API 重置(重新创建新令牌)前将一直有效。
|
||||
|
||||
令牌可用于注册多个 Runner，直到使用 Web 界面中的令牌重置链接将其撤销并替换为新令牌。
|
||||
|
||||
获取注册令牌后，请参阅 [Gitea Runner 文档](/runner/) 了解如何安装、配置和运行您的 Runner。
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
---
|
||||
date: "2026-06-26T00:00:00+00:00"
|
||||
slug: "scoped-workflows"
|
||||
sidebar_position: 60
|
||||
---
|
||||
|
||||
# 作用域工作流
|
||||
|
||||
作用域工作流（Scoped Workflows）让你把 Actions 工作流集中维护在一个**源（source）**仓库中，并让它们自动在许多其他仓库上运行，而无需把工作流文件复制到每个仓库里。
|
||||
|
||||
提交到源仓库作用域工作流目录下的工作流文件，会在该源所适用的每个仓库（称为**消费方（consuming）**仓库）上运行。每次运行都在**消费方仓库自身的上下文**中执行：使用它的 runner、密钥、`GITEA_TOKEN` 和分支，而工作流**内容则读取自源仓库**。这适用于在组织或实例范围内强制推行共享 CI：代码检查、安全扫描、合规或策略检查等。
|
||||
|
||||
## 级别
|
||||
|
||||
源仓库可以在两个级别注册：
|
||||
|
||||
- **所有者级别（Owner level）**：由组织或用户注册。该源的工作流会在该组织或用户拥有的每个仓库上运行。
|
||||
- **实例级别（Instance level）**：由站点管理员注册。该源的工作流会在实例上的**每一个**仓库上运行。
|
||||
|
||||
同一个仓库可以同时在两个级别注册；对于每个匹配的事件，它仍只会被评估一次。
|
||||
|
||||
:::note
|
||||
实例级别的源适用于实例上的**每一个**仓库，且被设为必需（required）的源无法被选择退出（opt out）。检测会在每个仓库的每次事件上运行。请谨慎注册。
|
||||
:::
|
||||
|
||||
## 配置
|
||||
|
||||
作用域工作流存放在一个与常规工作流分开的目录中，由 `app.ini` 中 `[actions]` 段的 `SCOPED_WORKFLOW_DIRS` 控制：
|
||||
|
||||
```ini
|
||||
[actions]
|
||||
SCOPED_WORKFLOW_DIRS = .gitea/scoped_workflows
|
||||
```
|
||||
|
||||
- 默认值为 `.gitea/scoped_workflows`。
|
||||
- 可以列出多个目录（以逗号分隔）。
|
||||
- **不得与** `WORKFLOW_DIRS`（常规工作流目录，默认为 `.gitea/workflows` 和 `.github/workflows`）**重叠**。
|
||||
- 留空意味着没有任何目录存放作用域工作流，因此不会找到也不会运行任何作用域工作流。设置页面仍会显示、源仍可注册，但不会有任何作用域工作流运行。
|
||||
|
||||
把作用域工作流放在它们自己的目录中，意味着源仓库**自身**的 Actions 不受影响：只有 `SCOPED_WORKFLOW_DIRS` 下的文件才会被当作作用域工作流。
|
||||
|
||||
## 从一个仓库提供作用域工作流
|
||||
|
||||
1. 在准备作为源的仓库中，把工作流文件提交到其**默认分支**上的作用域工作流目录下，例如 `.gitea/scoped_workflows/lint.yaml`：
|
||||
|
||||
```yaml
|
||||
name: Lint
|
||||
on: [push, pull_request]
|
||||
jobs:
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- run: echo "lint the consuming repository here"
|
||||
```
|
||||
|
||||
2. 将该仓库注册为源：
|
||||
|
||||
- **组织**：*组织设置 -> Actions -> 作用域工作流*
|
||||
- **用户**：*用户设置 -> Actions -> 作用域工作流*
|
||||
- **实例（管理员）**：*管理后台 -> Actions -> 作用域工作流*
|
||||
|
||||
搜索并添加该仓库。此后，它的作用域工作流便会适用于该级别下的消费方仓库。
|
||||
|
||||
源仓库也在它自己的作用域内，因此它会像其他消费方一样在自身上运行这些工作流。
|
||||
|
||||
## 作用域工作流如何运行
|
||||
|
||||
- 该运行属于**消费方**仓库，使用它的 runner、密钥、`GITEA_TOKEN` 和 ref。它在那里的表现与普通运行一致，包括重跑、日志和提交状态。
|
||||
- 工作流**内容读取自源**仓库，并钉定在事件发生时源默认分支的 commit 上。
|
||||
- 检测使用消费方仓库的事件，因此工作流的 `on:` 触发器（例如 `push` 和 `pull_request`）必须与该事件匹配。
|
||||
|
||||
## 选择退出（Opting out）
|
||||
|
||||
消费方仓库可以在其 **Actions** 页面（该工作流会显示在其源之下）禁用一个它不想要的作用域工作流。已被标记为**必需（required）**（见下文）的工作流，消费方仓库永远无法将其禁用，也无法选择退出。
|
||||
|
||||
## 必需工作流与合并门禁
|
||||
|
||||
在作用域工作流设置页面上，你可以把单个工作流标记为**必需（required）**，并为每个工作流给定一个或多个**状态检查模式（status-check patterns）**（每行一个 glob）。一个必需的作用域工作流：
|
||||
|
||||
- 无法被消费方仓库禁用。
|
||||
- 会对合并请求（PR）形成合并门禁：消费方的 PR 只有在一个匹配**每一个**模式的提交状态都**通过**后才能合并（必须存在且通过，must-present-and-pass）。一个从不产生任何状态的必需检查会**阻止**合并，而不是被静默跳过，因此在消费方关闭 Actions 也无法绕过它。
|
||||
|
||||
作用域运行产生的状态检查 context 形如：
|
||||
|
||||
```
|
||||
<源仓库全名>: <工作流显示名> / <job> (<event>)
|
||||
```
|
||||
|
||||
设置页面会为每个工作流预览这些 “Expected status checks（预期状态检查）”，并标记出与你的模式匹配的项，便于你确认模式是否正确。一种常见模式是对 job 和 event 使用通配符，例如 `my-org/ci-repo: Lint / *`。
|
||||
|
||||
强制范围：
|
||||
|
||||
- 必需检查会在任何设有**分支保护规则**的目标分支上强制生效，即使该规则自身的状态检查处于关闭状态。
|
||||
- **没有**保护规则的目标分支不受门禁约束。
|
||||
|
||||
:::warning
|
||||
只有运行在会产生提交状态的事件（`push`、`pull_request`、`pull_request_target`、`release`）上的工作流才能被设为必需。仅运行在 `workflow_dispatch`、`schedule` 或 `workflow_call` 等事件上的工作流不会产生任何状态，因此把它设为必需会**永久**阻止每一个消费方 PR 的合并。设置页面在这种情况下会向你发出警告。
|
||||
:::
|
||||
|
||||
## 可复用工作流（`uses:`）
|
||||
|
||||
作用域工作流可以调用可复用工作流：
|
||||
|
||||
- **本地**引用（`uses: ./...` 或 `uses: $/...`）会相对于**源**仓库解析：即调用方工作流内容的来源仓库，而非消费方仓库。
|
||||
- **跨仓库**引用（`uses: owner/repo/...@ref` 或 `uses: self:owner/repo/...@ref`）会以**消费方仓库的**读取权限来解析。如果它指向一个私有仓库，请确保每个消费方仓库都能读取它，否则工作流会在那里失败。
|
||||
|
||||
可复用工作流可以放在源仓库的 `SCOPED_WORKFLOW_DIRS`（或 `WORKFLOW_DIRS`）之下。
|
||||
|
||||
## 安全注意事项
|
||||
|
||||
源仓库的工作流内容会在它所适用的每个仓库中执行，其步骤脚本及其输出会写入该仓库的 Actions 日志，任何能查看消费方仓库 Actions 的人都能读取这些日志。
|
||||
|
||||
- 因此，将一个**私有**仓库注册为源，会通过这些日志泄露其工作流逻辑。只应注册那些其工作流内容可以与每个消费方仓库共享的仓库。
|
||||
|
||||
## 限制
|
||||
|
||||
- 目前不支持将 `on: schedule` 和 `on: workflow_run` 作为作用域工作流触发器。
|
||||
- 作用域工作流内容读取自源的默认分支；源的其他分支不会被使用。
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
date: "2023-05-23T09:00:00+08:00"
|
||||
slug: "secrets"
|
||||
sidebar_position: 50
|
||||
---
|
||||
|
||||
# 密钥管理
|
||||
|
||||
密钥管理允许您在用户、组织或仓库中存储敏感信息。
|
||||
密钥管理在 Gitea 1.19+ 版本中可用。
|
||||
|
||||
## 设置密钥名称
|
||||
|
||||
以下规则适用于密钥名称：
|
||||
|
||||
- 密钥名称只能包含字母数字字符 (`[a-z]`, `[A-Z]`, `[0-9]`) 或下划线 (`_`)。不允许使用空格。
|
||||
|
||||
- 密钥名称不能以 `GITHUB_` 和 `GITEA_` 前缀开头。
|
||||
|
||||
- 密钥名称不能以数字开头。
|
||||
|
||||
- 密钥名称不区分大小写。
|
||||
|
||||
- 密钥名称在创建它们的级别上必须是唯一的。
|
||||
|
||||
例如，对于在仓库级别创建的密钥，它在该仓库中必须具有唯一的名称；对于在组织级别创建的密钥，它在该级别上必须具有唯一的名称。
|
||||
|
||||
如果在多个级别上存在具有相同名称的密钥，则最低级别的密钥优先生效。例如，如果组织级别的密钥与仓库级别的密钥具有相同的名称，则仓库级别的密钥将优先生效。
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
date: "2026-03-19T00:00:00+01:00"
|
||||
slug: "token-permissions"
|
||||
sidebar_position: 30
|
||||
---
|
||||
|
||||
# Actions Job令牌权限（`GITEA_TOKEN`）
|
||||
|
||||
每个Actions Job都会获得一个内置令牌（`GITEA_TOKEN`），可用于访问Gitea（通过HTTP(S)访问Git、API请求等）。
|
||||
本页面介绍Gitea如何决定该令牌可以执行哪些操作。
|
||||
|
||||
在工作流中，可以通过`${{ secrets.GITEA_TOKEN }}`使用该令牌。这些设置和`permissions:`仅影响`GITEA_TOKEN`（不影响个人访问令牌等其他密钥）。关于API调用，请参阅[API认证](../../development/api-usage.md#authentication)。
|
||||
|
||||
<a id="where-permissions-come-from"></a>
|
||||
## 权限来源
|
||||
|
||||
Gitea按以下顺序确定Job令牌的权限：
|
||||
|
||||
1. Job级别的`permissions:`（`jobs.<job_id>.permissions`）
|
||||
2. 工作流级别的`permissions:`（顶层）
|
||||
3. 设置中的默认权限（所有者或仓库）
|
||||
|
||||
然后，该结果会受到所配置的最大令牌权限的**限制**（见下文）。
|
||||
|
||||
<a id="supported-workflow-syntax"></a>
|
||||
## 支持的工作流语法
|
||||
|
||||
Gitea支持与GitHub Actions兼容的`permissions:`关键字。
|
||||
|
||||
<a id="scalar-values"></a>
|
||||
### 标量值
|
||||
|
||||
```yaml
|
||||
permissions: read-all # or: write-all
|
||||
```
|
||||
|
||||
<a id="scoped-mapping"></a>
|
||||
### 按权限范围映射
|
||||
|
||||
```yaml
|
||||
permissions:
|
||||
contents: read
|
||||
issues: write
|
||||
pull-requests: none
|
||||
```
|
||||
|
||||
每个权限范围的有效访问模式值为`read`、`write`和`none`。
|
||||
|
||||
<a id="supported-scopes"></a>
|
||||
### 支持的权限范围
|
||||
|
||||
- `contents`（适用于`code`和`releases`）
|
||||
- `code`
|
||||
- `releases`
|
||||
- `issues`
|
||||
- `pull-requests`
|
||||
- `actions`
|
||||
- `wiki`
|
||||
- `projects`
|
||||
- `packages`（如果目标功能支持）
|
||||
|
||||
如果同时指定了`contents`和更细粒度的权限范围（如`code`或`releases`），则该单元以更细粒度的权限范围为准。
|
||||
|
||||
<a id="compatibility-notes"></a>
|
||||
### 兼容性说明
|
||||
|
||||
Gitea支持GitHub Actions权限范围的一个子集。
|
||||
Gitea Actions目前不支持`statuses`、`checks`、`deployments`、`id-token`、`security-events`和`pages`等GitHub专有的权限范围。
|
||||
|
||||
Gitea还提供了一些仓库单元权限范围，它们在GitHub Actions中不作为独立的权限范围存在：
|
||||
|
||||
- `code`
|
||||
- `releases`
|
||||
- `wiki`
|
||||
- `projects`
|
||||
|
||||
<a id="default-permission-mode"></a>
|
||||
## 默认权限模式
|
||||
|
||||
如果工作流和Job都没有定义`permissions:`，Gitea会使用所配置的默认模式：
|
||||
|
||||
- **宽松**：对Job所属仓库的大多数单元拥有读写权限（向后兼容的默认值）。
|
||||
- **受限**：对Job所属仓库的`code`、`releases`和`packages`拥有只读权限，默认无权访问其他单元。
|
||||
|
||||
<a id="maximum-token-permissions-clamping"></a>
|
||||
## 最大令牌权限（限制）
|
||||
|
||||
您可以为每个仓库单元配置最大权限。
|
||||
Job的实际权限按以下方式计算：
|
||||
|
||||
`effective = min(requested, maximum)`
|
||||
|
||||
这意味着工作流可以降低Job的权限，但不能超过您配置的最大权限。
|
||||
如果未配置最大权限，则所有权限范围的最大权限默认为`write`。
|
||||
|
||||
<a id="where-to-configure"></a>
|
||||
## 配置位置
|
||||
|
||||
您可以在以下位置配置默认权限和最大权限：
|
||||
|
||||
- **用户/组织**：`Settings` → `Actions` → `General`
|
||||
- **仓库**：`Settings` → `Actions` → `General`
|
||||
- 对于组织中的仓库，可以遵循所有者级别的配置，也可以通过**覆盖所有者级别的配置**选择不遵循。
|
||||
|
||||
注意：仅在启用**仓库Actions**后，才会显示仓库级别的令牌权限设置。
|
||||
|
||||
<a id="fork-pull-requests"></a>
|
||||
## Fork拉取请求
|
||||
|
||||
出于安全考虑，由fork拉取请求触发的工作流始终只拥有仓库内容的只读权限，与工作流的`permissions:`或设置无关。
|
||||
|
||||
<a id="cross-repository-access"></a>
|
||||
## 跨仓库访问
|
||||
|
||||
默认情况下，`GITEA_TOKEN`只能访问：
|
||||
|
||||
- Job所属仓库（依据计算出的权限）
|
||||
- 公开仓库（只读）
|
||||
|
||||
默认拒绝访问其他私有仓库。
|
||||
用户或组织可以通过**设置 → Actions → 常规 → 跨仓库访问**，允许以只读方式访问选定的私有仓库。
|
||||
|
||||
私有仓库也可以通过**设置 → Actions → 常规**允许选定的协作所有者。
|
||||
这样，这些所有者的私有仓库便可读取当前私有仓库以供Actions使用，例如私有Actions和可复用工作流。
|
||||
|
||||
fork拉取请求的工作流永远不会获得对私有仓库的跨仓库访问权限，即使这些仓库已被列出。
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
date: "2024-04-10T22:21:00+08:00"
|
||||
slug: "actions-variables"
|
||||
sidebar_position: 25
|
||||
---
|
||||
|
||||
# 变量
|
||||
|
||||
您可以创建用户、组织和仓库级别的变量。变量的级别取决于创建它的位置。当创建变量时，变量的名称会被
|
||||
转换为大写，在yaml文件中引用时需要使用大写。
|
||||
|
||||
## 命名规则
|
||||
|
||||
以下规则适用于变量名：
|
||||
|
||||
- 变量名称只能包含字母数字字符 (`[a-z]`, `[A-Z]`, `[0-9]`) 或下划线 (`_`)。不允许使用空格。
|
||||
- 变量名称不能以 `GITHUB_` 和 `GITEA_` 前缀开头。
|
||||
- 变量名称不能以数字开头。
|
||||
- 变量名称不区分大小写。
|
||||
- 变量名称在创建它们的级别上必须是唯一的。
|
||||
- 变量名称不能为 `CI`。
|
||||
|
||||
## 使用
|
||||
|
||||
创建配置变量后，它们将自动填充到 `vars` 上下文中。您可以在工作流中使用类似 `${{ vars.VARIABLE_NAME }}` 这样的表达式来使用它们。
|
||||
|
||||
## 优先级
|
||||
|
||||
如果同名变量存在于多个级别，则级别最低的变量优先。
|
||||
仓库级别的变量总是比组织或者用户级别的变量优先被选中。
|
||||
Reference in new issue
Block a user