Add 1.27 rc0 documentation (#453)

Reviewed-on: https://gitea.com/gitea/docs/pulls/453
Reviewed-by: Zettat123 <39446+zettat123@noreply.gitea.com>
This commit is contained in:
Lunny Xiao
2026-07-01 17:14:52 +00:00
parent 24fdff218d
commit 1033f033bc
328 changed files with 75235 additions and 275 deletions

View File

@@ -0,0 +1,9 @@
{
"label": "仓库",
"position": 10,
"link": {
"type": "generated-index",
"slug": "/usage/repository",
"description": "仓库管理Git操作和内容功能"
}
}

View File

@@ -0,0 +1,18 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "clone-filters"
sidebar_position: 25
aliases:
- /zh-cn/clone-filters
---
# 克隆过滤器 (部分克隆)
Git 引入了 `--filter` 选项用于 `git clone` 命令,该选项可以过滤掉大文件和对象(如 blob从而创建一个仓库的部分克隆。克隆过滤器对于大型仓库和/或按流量计费的连接特别有用,因为完全克隆(不使用 `--filter`)可能会很昂贵(需要下载所有历史数据)。
这需要 Git 2.22 或更高版本,无论是在 Gitea 服务器上还是在客户端上都需要如此。为了使克隆过滤器正常工作,请确保客户端上的 Git 版本至少与服务器上的版本相同(或更高)。以管理员身份登录到 Gitea然后转到管理后台 -> 应用配置,查看服务器的 Git 版本。
默认情况下,克隆过滤器是启用的,除非在 `[git]` 下将 `DISABLE_PARTIAL_CLONE` 设置为 `true`
请参阅 [GitHub 博客文章:了解部分克隆](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/) 以获取克隆过滤器的常见用法(无 Blob 和无树的克隆),以及 [GitLab 部分克隆文档](https://docs.gitlab.com/ee/topics/git/partial_clone.html) 以获取更高级的用法(例如按文件大小过滤和取消过滤以将部分克隆转换为完全克隆)。

View File

@@ -0,0 +1,38 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "incoming-email"
sidebar_position: 13
aliases:
- /zh-cn/incoming-email
---
# 邮件接收
Gitea 支持通过接收邮件执行多种操作。本页面描述了如何进行设置。
## 要求
处理接收的电子邮件需要启用 IMAP 功能的电子邮件帐户。
推荐的策略是使用 [电子邮件子地址](https://en.wikipedia.org/wiki/Email_address#Sub-addressing),但也可以使用 catch-all 邮箱。
接收电子邮件地址中包含一个用户/操作特定的令牌,告诉 Gitea 应执行哪个操作。
此令牌应该出现在 `To``Delivered-To` 头字段中。
Gitea 会尝试检测自动回复并跳过它们,电子邮件服务器也应该配置以减少接收到的干扰(垃圾邮件、通讯订阅等)。
## 配置
要激活处理接收的电子邮件消息功能,您需要在配置文件中配置 `email.incoming` 部分。
`REPLY_TO_ADDRESS` 包含电子邮件客户端将要回复的地址。
该地址需要包含 `%{token}` 占位符,该占位符将被替换为描述用户/操作的令牌。
此占位符在地址中只能出现一次,并且必须位于地址的用户部分(`@` 之前)。
使用电子邮件子地址的示例可能如下:`incoming+%{token}@example.com`
如果使用 catch-all 邮箱,则占位符可以出现在地址的用户部分的任何位置:`incoming+%{token}@example.com``incoming_%{token}@example.com``%{token}@example.com`
## 安全性
在选择用于接收传入电子邮件的域时要小心。
建议在子域名上接收传入电子邮件,例如 `incoming.example.com`,以防止与运行在 `example.com` 上的其他服务可能存在的安全问题。

View File

@@ -0,0 +1,15 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "profile-readme"
sidebar_position: 12
---
# 个人资料 README
要在您的 Gitea 个人资料页面显示一个 Markdown 文件,只需创建一个名为 `.profile` 的仓库,并编辑其中的 `README.md` 文件。Gitea 将自动获取该文件并在您的仓库上方显示。
注意您可以将此仓库设为私有。这样可以隐藏您的源文件使其对公众不可见并允许您将某些文件设为私有。但是README.md 文件将是您个人资料上唯一存在的文件。如果您希望完全私有化 .profile 仓库,则需删除或重命名 README.md 文件。
用户示例 `.profile/README.md`:
![个人资料自述文件截图](/images/usage/profile-readme.png)

View File

@@ -0,0 +1,61 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "push"
sidebar_position: 15
aliases:
- /zh-cn/push-to-create
- /zh-cn/push-options
---
# 推送
在将提交推送到 Gitea 服务器时,还有一些额外的功能。
## 通过推送打开 PR
当您第一次将提交推送到非默认分支时,您将收到一个链接,您可以单击该链接访问分支与主分支的比较页面。
从那里,您可以轻松创建一个拉取请求,即使您想要将其目标指向另一个分支。
![Gitea 推送提示](/gitea-push-hint.png)
## 推送选项
在 Gitea `1.13` 版本中,添加了对一些 [推送选项](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt) 的支持。
### 支持的选项
- `repo.private` (true|false) - 更改仓库的可见性。
这在与 push-to-create 结合使用时特别有用。
- `repo.template` (true|false) - 更改仓库是否为模板。
将仓库的可见性更改为公开的示例:
```shell
git push -o repo.private=false -u origin main
```
## 推送创建
推送创建是一项功能,允许您将提交推送到在 Gitea 中尚不存在的仓库。这对于自动化和允许用户创建仓库而无需通过 Web 界面非常有用。此功能默认处于禁用状态。
### 启用推送创建
`app.ini` 文件中,将 `ENABLE_PUSH_CREATE_USER` 设置为 `true`,如果您希望允许用户在自己的用户帐户和所属的组织中创建仓库,将 `ENABLE_PUSH_CREATE_ORG` 设置为 `true`。重新启动 Gitea 以使更改生效。您可以在 [配置速查表](../administration/config-cheat-sheet.md#仓库) 中了解有关这两个选项的更多信息。
### 使用推送创建
假设您在当前目录中有一个 git 仓库,您可以通过运行以下命令将提交推送到在 Gitea 中尚不存在的仓库:
```shell
# 添加要推送到的远程仓库
git remote add origin git@{domain}:{username}/{尚不存在的仓库名称}.git
# 推送到远程仓库
git push -u origin main
```
这假设您使用的是 SSH 远程,但您也可以使用 HTTPS 远程。
推送创建将默认使用 `app.ini` 中定义的可见性 `DEFAULT_PUSH_CREATE_PRIVATE`

View File

@@ -0,0 +1,98 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "repo-mirror"
sidebar_position: 45
aliases:
- /zh-cn/repo-mirror
---
# 仓库镜像
仓库镜像允许将仓库与外部源之间进行镜像。您可以使用它在仓库之间镜像分支、标签和提交。
## 使用场景
以下是一些仓库镜像的可能使用场景:
- 您迁移到了 Gitea但仍需要在其他源中保留您的项目。在这种情况下您可以简单地设置它以进行镜像到 Gitea拉取这样您的 Gitea 实例中就可以获取到所有必要的提交历史、标签和分支。
- 您在其他源中有一些旧项目,您不再主动使用,但出于归档目的不想删除。在这种情况下,您可以创建一个推送镜像,以便您的活跃的 Gitea 仓库可以将其更改推送到旧位置。
## 从远程仓库拉取
对于现有的远程仓库,您可以按照以下步骤设置拉取镜像:
1. 在右上角的“创建...”菜单中选择“迁移外部仓库”。
2. 选择远程仓库服务。
3. 输入仓库的 URL。
4. 如果仓库需要身份验证,请填写您的身份验证信息。
5. 选中“该仓库将是一个镜像”复选框。
6. 选择“迁移仓库”以保存配置。
现在,该仓库会定期从远程仓库进行镜像。您可以通过在仓库设置中选择“立即同步”来强制进行同步。
:::warning
:exclamation::exclamation: **注意:**您只能为尚不存在于您的实例上的仓库设置拉取镜像。一旦仓库创建成功,您就无法再将其转换为拉取镜像。:exclamation::exclamation:
:::
## 推送到远程仓库
对于现有的仓库,您可以按照以下步骤设置推送镜像:
1. 在仓库中,转到**设置** > **仓库**,然后进入**镜像设置**部分。
2. 输入一个仓库的 URL。
3. 如果仓库需要身份验证,请展开**授权**部分并填写您的身份验证信息。请注意,所请求的**密码**也可以是您的访问令牌。
4. 选择**添加推送镜像**以保存配置。
该仓库现在会定期镜像到远程仓库。您可以通过选择**立即同步**来强制同步。如果出现错误,会显示一条消息帮助您解决问题。
:::warning
:exclamation::exclamation: **注意:** 这将强制推送到远程仓库。这将覆盖远程仓库中的任何更改! :exclamation::exclamation:
:::
### 从 Gitea 向 GitHub 设置推送镜像
要从 Gitea 设置镜像到 GitHub您需要按照以下步骤进行操作
1. 创建一个具有选中 _public_repo_ 选项的 [GitHub 个人访问令牌](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token)。
2. 在 GitHub 上创建一个同名的仓库。与 Gitea 不同GitHub 不支持通过推送到远程来创建仓库。如果您的现有远程仓库与您的 Gitea 仓库具有相同的提交历史,您也可以使用现有的远程仓库。
3. 在您的 Gitea 仓库设置中,填写**Git 远程仓库 URL**`https://github.com/<your_github_group>/<your_github_project>.git`
4. 使用您的 GitHub 用户名填写**授权**字段,并将个人访问令牌作为**密码**。
5. (可选,适用于 Gitea 1.18+)选择`当推送新提交时同步`,这样一旦有更改,镜像将会及时更新。如果您愿意,您还可以禁用定期同步。
6. 选择**添加推送镜像**以保存配置。
仓库会很快进行推送。要强制推送,请选择**立即同步**按钮。
### 从 Gitea 向 GitLab 设置推送镜像
要从 Gitea 设置镜像到 GitLab您需要按照以下步骤进行操作
1. 创建具有 _write_repository_ 作用域的 [GitLab 个人访问令牌](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html)。
2. 填写**Git 远程仓库 URL**`https://<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`
3. 在**授权**字段中填写 `oauth2` 作为**用户名**,并将您的 GitLab 个人访问令牌作为**密码**。
4. 选择**添加推送镜像**以保存配置。
仓库会很快进行推送。要强制推送,请选择**立即同步**按钮。
### 从 Gitea 向 Bitbucket 设置推送镜像
要从 Gitea 设置镜像到 Bitbucket您需要按照以下步骤进行操作
1. 创建一个具有选中 _Repository Write_ 选项的 [Bitbucket 应用密码](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/)。
2. 填写**Git 远程仓库 URL**`https://bitbucket.org/<your_bitbucket_group_or_name>/<your_bitbucket_project>.git`
3. 使用您的 Bitbucket 用户名填写**授权**字段,并将应用密码作为**密码**。
4. 选择**添加推送镜像**以保存配置。
仓库会很快进行推送。要强制推送,请选择**立即同步**按钮。
### 镜像现有的 ssh 仓库
当前Gitea 不支持从 ssh 仓库进行镜像。如果您想要镜像一个 ssh 仓库,您需要将其转换为 http 仓库。您可以使用以下命令将现有的 ssh 仓库转换为 http 仓库:
1. 确保运行 gitea 的用户有权限访问您试图从 shell 镜像到的 git 仓库。
2. 在 Web 界面的版本库设置 > git 钩子中为镜像添加一个接收后钩子。
```
#!/usr/bin/env bash
git push --mirror --quiet git@github.com:username/repository.git &>/dev/null &
echo "GitHub mirror initiated .."
```

View File

@@ -0,0 +1,76 @@
---
date: "2023-05-23T09:00:00+08:00"
slug: "template-repositories"
sidebar_position: 14
aliases:
- /zh-cn/template-repositories
---
# 模板仓库
Gitea `1.11.0` 及以上版本引入了模板仓库,并且其中一个实现的功能是自动展开模板文件中的特定变量。
要告诉 Gitea 哪些文件需要展开,您必须在模板仓库的 `.gitea` 目录中包含一个 `template` 文件。
Gitea 使用 [gobwas/glob](https://github.com/gobwas/glob) 作为其 glob 语法。它与传统的 `.gitignore` 语法非常相似,但可能存在细微的差异。
## `.gitea/template` 文件示例
所有路径都是相对于仓库的根目录
```gitignore
# 仓库中的所有 .go 文件
**.go
# text 目录中的所有文本文件
text/*.txt
# 特定文件
a/b/c/d.json
# 匹配批处理文件的大小写变体
**.[bB][aA][tT]
```
**注意:** 当从模板生成仓库时,`.gitea` 目录中的 `template` 文件将被删除。
## 参数展开
在与上述通配符匹配的任何文件中,将会扩展某些变量。
文件名和路径的匹配也可以被扩展,并且会经过谨慎的清理处理,以支持跨平台的文件系统。
所有变量都必须采用`$VAR``${VAR}`的形式。要转义扩展,使用双重`$$`,例如`$$VAR``$${VAR}`
| 变量 | 扩展为 | 可转换 |
| -------------------- | ----------------------------- | ------ |
| REPO_NAME | 生成的仓库名称 | ✓ |
| TEMPLATE_NAME | 模板仓库名称 | ✓ |
| REPO_DESCRIPTION | 生成的仓库描述 | ✘ |
| TEMPLATE_DESCRIPTION | 模板仓库描述 | ✘ |
| REPO_OWNER | 生成的仓库所有者 | ✓ |
| TEMPLATE_OWNER | 模板仓库所有者 | ✓ |
| REPO_LINK | 生成的仓库链接 | ✘ |
| TEMPLATE_LINK | 模板仓库链接 | ✘ |
| REPO_HTTPS_URL | 生成的仓库的 HTTP(S) 克隆链接 | ✘ |
| TEMPLATE_HTTPS_URL | 模板仓库的 HTTP(S) 克隆链接 | ✘ |
| REPO_SSH_URL | 生成的仓库的 SSH 克隆链接 | ✘ |
| TEMPLATE_SSH_URL | 模板仓库的 SSH 克隆链接 | ✘ |
## 转换器 :robot:
Gitea `1.12.0` 添加了一些转换器以应用于上述适用的变量。
例如,要以 `PASCAL`-case 获取 `REPO_NAME`,你的模板应使用 `${REPO_NAME_PASCAL}`
`go-sdk` 传递给可用的转换器的效果如下...
| 转换器 | 效果 |
| ------ | ------ |
| SNAKE | go_sdk |
| KEBAB | go-sdk |
| CAMEL | goSdk |
| PASCAL | GoSdk |
| LOWER | go-sdk |
| UPPER | GO-SDK |
| TITLE | Go-Sdk |

View File

@@ -0,0 +1,720 @@
---
date: "2016-12-01T16:00:00+02:00"
slug: "webhooks"
sidebar_position: 30
aliases:
- /zh-cn/webhooks
---
# Webhooks
Gitea 可以为仓库活动发送出站 Webhook。仓库级 Webhook 由仓库管理员在
`/:username/:reponame/settings/hooks` 中配置。组织、用户和系统管理级别
也有对应的 Webhook 配置页面。
Webhook 配置支持四种作用域:
- `仓库 Webhook`:仅对单个仓库中的活动触发。
- `组织 Webhook`:对该组织拥有的仓库中的活动触发。
- `用户 Webhook`:对该用户拥有的仓库中的活动触发。
- `系统 Webhook`:对实例中的所有符合条件的活动触发。
Gitea 还支持由管理员定义的 `默认 Webhook`。它并不是额外的投递作用域,
而是会在新仓库创建时被复制到仓库中,之后按普通仓库 Webhook 的方式工作。
Gitea 支持以下出站 Webhook 集成:
- Gitea
- Gogs
- Slack
- Discord
- Dingtalk
- Telegram
- Microsoft Teams
- Feishu
- Matrix
- Wechatwork
- Packagist
`Gitea``Gogs` 类型会发送通用 Webhook 负载。上面列出的聊天和服务集成
会将同一个内部事件转换为各自服务所需的请求体格式。
本页分为三个部分:
- `配置`:如何配置 Webhook 设置,例如 URL、密钥、分支过滤器和授权头。
- `投递`Gitea 如何发送 Webhook 请求、会携带哪些请求头,以及如何校验投递。
- `事件`Gitea 会投递哪些事件,以及每个事件包含哪些顶层 payload 参数。
## 配置
本节介绍在创建或编辑 Webhook 时可以设置的选项。
### 配置 Webhook
创建 Webhook 时,主要配置项包括:
- `Target URL`:接收投递的目标地址。
- `HTTP Method`:通用 Webhook 通常使用 `POST`
- `POST Content Type`:通用 Webhook 可使用 `application/json`
`application/x-www-form-urlencoded`
- `Secret`:用于对原始请求体进行 HMAC 签名。
- `Authorization Header`:可选的自定义 `Authorization` 请求头,会随每次请求发送。
- `Branch Filter`:可选的分支或标签过滤规则。
- `Trigger On``Push Events``All Events` 或自定义事件选择。
- `Active`:是否启用该 Webhook。
:::note
旧示例里可能仍会在 JSON payload 中看到 `secret` 字段。当前版本的 Gitea
不会再把 Webhook 密钥放进 payload 正文中。请始终通过签名请求头来验证请求。
:::
### 分支过滤器
分支过滤器使用与
[`github.com/gobwas/glob`](https://pkg.go.dev/github.com/gobwas/glob#Compile)
兼容的 glob 语法。
- 空值、`*``**` 表示匹配全部。
-`main` 这样的普通分支名会匹配该分支。
- 也支持 `refs/tags/v*` 这样的完整 ref。
- 支持 `{main,release/*}` 这样的花括号表达式。
- 过滤器只对带 git ref 的事件生效,例如 `create``delete``push`
- 不带 ref 的事件,例如 issue 或 release会忽略分支过滤器。
示例:
- `main`
- `{main,feature/*}`
- `{refs/heads/feature/*,refs/tags/release/*}`
### 授权头
Gitea 可以配置为在每次 Webhook 投递时发送自定义
[Authorization header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization)。
它与 Webhook 密钥是相互独立的:
- 使用密钥通过 HMAC 校验请求完整性。
- 当接收端需要应用层认证时,使用 `Authorization` 请求头。
## 投递
本节说明 Gitea 如何发送 Webhook 投递,以及接收端如何识别和验证这些请求。
### 投递行为
- Webhook 会通过 HTTP 异步投递。
- 通用 `Gitea``Gogs` Webhook 支持 `POST``GET`;通常应使用 `POST`
- 对于 `POST` 请求payload 可以直接作为 JSON
`application/json`)发送,也可以放在名为 `payload` 的表单字段中
`application/x-www-form-urlencoded`)。
- 某些特定服务的集成可能会使用该服务要求的 HTTP 方法和请求体格式。
### 投递请求头
每次投递都包含唯一的 delivery ID 和事件请求头。对于兼容 GitHub 的集成,
Gitea 也会同时发送对应的 GitHub 和 Gogs 风格请求头。
| 请求头 | 说明 |
| --- | --- |
| `X-Gitea-Delivery` | 本次投递尝试的唯一 UUID。 |
| `X-Gitea-Event` | 规范化事件名,例如 `push``issues``pull_request`。 |
| `X-Gitea-Event-Type` | 更具体的事件类型,例如 `issue_assign``pull_request_review_comment`。 |
| `X-Gitea-Signature` | 原始请求体的十六进制 HMAC-SHA256 值,不带前缀。 |
| `X-Gitea-Hook-Installation-Target-Type` | Webhook 定义所在范围,通常是 `repository``organization``user``system`。默认 Webhook 会先复制到仓库后再投递,因此通常会表现为 `repository`。 |
| `X-Gogs-Delivery``X-Gogs-Event``X-Gogs-Event-Type``X-Gogs-Signature` | 与 Gitea 对应请求头值相同的兼容请求头。 |
| `X-GitHub-Delivery``X-GitHub-Event``X-GitHub-Event-Type` | GitHub 风格兼容请求头。 |
| `X-GitHub-Hook-Installation-Target-Type` | GitHub 风格的 Webhook 作用域请求头。 |
| `X-Hub-Signature` | GitHub 兼容的 HMAC-SHA1 请求头,格式为 `sha1=<digest>`。 |
| `X-Hub-Signature-256` | GitHub 兼容的 HMAC-SHA256 请求头,格式为 `sha256=<digest>`。 |
如果未配置密钥,签名请求头仍然会存在,但摘要值为空。
#### `Event` 与 `Event-Type`
某些 Gitea Webhook 订阅会被归类到同一个规范化事件名下。例如issue 指派
投递会归类到 issue 事件组:
```http
X-Gitea-Event: issues
X-Gitea-Event-Type: issue_assign
X-GitHub-Event: issues
X-GitHub-Event-Type: issue_assign
```
如果你需要知道真正触发投递的具体事件类型,请使用 `X-Gitea-Event-Type`
#### 校验投递
Gitea 会使用你的 Webhook 密钥对原始请求体进行签名。要校验一次投递:
1. 按接收到的原始内容读取请求体。
2. 使用 Webhook 密钥计算 HMAC-SHA256 摘要。
3. 将结果与 `X-Gitea-Signature` 或 GitHub 兼容的
`X-Hub-Signature-256` 进行比较。
4. 尽量使用常量时间比较函数。
注意事项:
- `X-Gitea-Signature` 仅包含小写十六进制的 SHA-256 摘要。
- `X-Hub-Signature-256` 使用相同摘要,但带有 `sha256=` 前缀。
- `X-Hub-Signature` 也会出于兼容性目的发送,其算法是 SHA-1。
- 在完成签名校验之前,不应先解析 JSON 或修改请求体。
##### PHP 示例
下面的示例演示如何校验以 `application/json` 发送的通用 `Gitea` Webhook。
```php
<?php
$secret = '123';
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
http_response_code(405);
exit('Only POST is allowed');
}
$payload = file_get_contents('php://input');
$signature = $_SERVER['HTTP_X_GITEA_SIGNATURE'] ?? '';
if ($payload === false || $signature === '') {
http_response_code(400);
exit('Missing payload or signature');
}
$expected = hash_hmac('sha256', $payload, $secret);
if (!hash_equals($expected, $signature)) {
http_response_code(401);
exit('Invalid signature');
}
$event = $_SERVER['HTTP_X_GITEA_EVENT'] ?? '';
$eventType = $_SERVER['HTTP_X_GITEA_EVENT_TYPE'] ?? '';
$data = json_decode($payload, true);
if (!is_array($data)) {
http_response_code(400);
exit('Invalid JSON payload');
}
http_response_code(204);
```
## 事件
本节采用与 GitHub Webhook 文档类似的按事件逐项描述方式:每个事件都会说明
其触发时机,以及 payload 中包含哪些顶层字段。
事件分组与 Webhook 设置界面中的分组一致:`Repository Events`
`Issue Events``Pull Request Events``Workflow Events`
### 仓库事件
- `create``delete``fork``push``wiki``repository``release``package``status`
#### `create`
当分支或标签被创建时,会触发此事件。
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `sha` | `string` | **必填。** 新建引用对应的对象 ID。 |
| `ref` | `string` | **必填。** 被创建的分支名或标签名。 |
| `ref_type` | `string` | **必填。** 引用类型,例如 `branch``tag`。 |
| `repository` | `object` | **必填。** 创建该引用的仓库。 |
| `sender` | `object` | **必填。** 创建该引用的用户。 |
#### `delete`
当分支或标签被删除时,会触发此事件。
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `ref` | `string` | **必填。** 被删除的分支名或标签名。 |
| `ref_type` | `string` | **必填。** 引用类型,例如 `branch``tag`。 |
| `pusher_type` | `string` | **必填。** 删除该 ref 的行为主体类型。当前 Gitea payload 中使用 `user`。 |
| `repository` | `object` | **必填。** 删除该引用所在的仓库。 |
| `sender` | `object` | **必填。** 删除该引用的用户。 |
#### `fork`
当仓库被 fork 时,会触发此事件。
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `forkee` | `object` | **必填。** 新创建的 fork 仓库。 |
| `repository` | `object` | **必填。** 被 fork 的原始仓库。 |
| `sender` | `object` | **必填。** 创建 fork 的用户。 |
#### `push`
当提交被推送到某个分支或标签时,会触发此事件。
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `ref` | `string` | **必填。** 被推送的完整 ref例如 `refs/heads/main`。 |
| `before` | `string` | **必填。** 推送前的提交 SHA。 |
| `after` | `string` | **必填。** 推送后的提交 SHA。 |
| `compare_url` | `string` | **必填。** 用于比较 `before``after` 的 URL。 |
| `commits` | `array` | **必填。** 本次推送包含的提交列表。 |
| `total_commits` | `integer` | **必填。** 本次推送中的提交数量。 |
| `head_commit` | `object` | 本次推送中的最新提交。 |
| `repository` | `object` | **必填。** 接收此次推送的仓库。 |
| `pusher` | `object` | **必填。** 执行推送的用户。 |
| `sender` | `object` | **必填。** 触发 Webhook 的用户。 |
#### `wiki`
当 Wiki 页面被创建、编辑或删除时,会触发此事件。
**动作类型:** `created``edited``deleted`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** Wiki 页面操作类型。 |
| `repository` | `object` | **必填。** 拥有该 Wiki 的仓库。 |
| `sender` | `object` | **必填。** 修改 Wiki 页面的用户。 |
| `page` | `string` | **必填。** Wiki 页面名称。 |
| `comment` | `string` | Wiki 提交信息或备注。 |
#### `repository`
当仓库被创建或删除时,会触发此事件。
**动作类型:** `created``deleted`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 仓库操作类型。 |
| `repository` | `object` | **必填。** 被创建或删除的仓库。 |
| `organization` | `object` | 当仓库属于某个组织时会出现。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
#### `release`
当发布版本被发布、更新或删除时,会触发此事件。
**动作类型:** `published``updated``deleted`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** Release 操作类型。 |
| `release` | `object` | **必填。** 被操作的发布版本。 |
| `repository` | `object` | **必填。** 包含该发布版本的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
#### `package`
当包被创建或删除时,会触发此事件。
**动作类型:** `created``deleted`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 包操作类型。 |
| `repository` | `object` | 与该包关联的仓库;如果适用则会出现。 |
| `package` | `object` | **必填。** 被操作的包。 |
| `organization` | `object` | 当包所有者是组织时会出现。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
#### `status`
当通过 API 创建或更新提交状态时,会触发此事件。
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `commit` | `object` | 与该状态关联的提交。 |
| `context` | `string` | **必填。** 状态上下文,例如 `ci/build`。 |
| `created_at` | `string` | **必填。** 状态创建时间。 |
| `description` | `string` | 状态描述文本。 |
| `id` | `integer` | **必填。** 状态标识符。 |
| `repository` | `object` | **必填。** 包含该提交的仓库。 |
| `sender` | `object` | **必填。** 创建该状态的用户。 |
| `sha` | `string` | **必填。** 提交 SHA。 |
| `state` | `string` | **必填。** 状态值,例如 `pending``success``error``failure`。 |
| `target_url` | `string` | 与该状态关联的目标 URL。 |
| `updated_at` | `string` | 状态最后更新时间。 |
与多数其他 payload 不同,此事件不使用 `action` 字段,状态变化通过 `state`
字段表示。
### 议题事件
- `issues``issue_assign``issue_label``issue_milestone``issue_comment`
#### `issues`
当 issue 被打开、关闭、重新打开、编辑或删除时,会触发此事件。
**动作类型:** `opened``closed``reopened``edited``deleted`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** Issue 操作类型。 |
| `number` | `integer` | **必填。** Issue 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `issue` | `object` | **必填。** 被操作的 issue。 |
| `repository` | `object` | **必填。** 包含该 issue 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 issue 操作关联的提交 SHA如果适用则会出现。 |
#### `issue_assign`
当 issue 被指派或取消指派时,会触发此事件。
**动作类型:** `assigned``unassigned`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 指派操作类型。 |
| `number` | `integer` | **必填。** Issue 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `issue` | `object` | **必填。** 被操作的 issue。 |
| `repository` | `object` | **必填。** 包含该 issue 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 issue 操作关联的提交 SHA如果适用则会出现。 |
#### `issue_label`
当 issue 标签被更新或清空时,会触发此事件。
**动作类型:** `label_updated``label_cleared`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 标签更新操作类型。 |
| `number` | `integer` | **必填。** Issue 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `issue` | `object` | **必填。** 被操作的 issue。 |
| `repository` | `object` | **必填。** 包含该 issue 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 issue 操作关联的提交 SHA如果适用则会出现。 |
#### `issue_milestone`
当 issue 被设置里程碑或移除里程碑时,会触发此事件。
**动作类型:** `milestoned``demilestoned`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 里程碑操作类型。 |
| `number` | `integer` | **必填。** Issue 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `issue` | `object` | **必填。** 被操作的 issue。 |
| `repository` | `object` | **必填。** 包含该 issue 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 issue 操作关联的提交 SHA如果适用则会出现。 |
#### `issue_comment`
当 issue 评论被创建、编辑或删除时,会触发此事件。
**动作类型:** `created``edited``deleted`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 评论操作类型。 |
| `issue` | `object` | **必填。** 该评论所属的 issue。 |
| `pull_request` | `object` | 当该评论位于 pull request 时间线上时会出现。 |
| `comment` | `object` | **必填。** 被创建、编辑或删除的评论。 |
| `changes` | `object` | 可选。当操作类型为 `edited` 时,表示评论正文的旧值。 |
| `repository` | `object` | **必填。** 包含该 issue 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `is_pull` | `boolean` | **必填。** 该评论是否位于 pull request 时间线上。 |
### Pull Request 事件
- `pull_request``pull_request_assign``pull_request_label``pull_request_milestone``pull_request_comment``pull_request_review``pull_request_review_approved``pull_request_review_rejected``pull_request_review_comment``pull_request_sync``pull_request_review_request`
#### `pull_request`
当 pull request 被打开、关闭、重新打开、编辑或删除时,会触发此事件。
**动作类型:** `opened``closed``reopened``edited``deleted`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** Pull request 操作类型。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被操作的 pull request。 |
| `requested_reviewer` | `object` | 在评审请求事件中会出现。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 pull request 操作关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | 在 pull request review 事件中会出现。 |
#### `pull_request_assign`
当 pull request 被指派或取消指派时,会触发此事件。
**动作类型:** `assigned``unassigned`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 指派操作类型。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被操作的 pull request。 |
| `requested_reviewer` | `object` | 在评审请求事件中会出现。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 pull request 操作关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | 在 pull request review 事件中会出现。 |
#### `pull_request_label`
当 pull request 标签被更新或清空时,会触发此事件。
**动作类型:** `label_updated``label_cleared`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 标签更新操作类型。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被操作的 pull request。 |
| `requested_reviewer` | `object` | 在评审请求事件中会出现。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 pull request 操作关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | 在 pull request review 事件中会出现。 |
#### `pull_request_milestone`
当 pull request 被设置里程碑或移除里程碑时,会触发此事件。
**动作类型:** `milestoned``demilestoned`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 里程碑操作类型。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被操作的 pull request。 |
| `requested_reviewer` | `object` | 在评审请求事件中会出现。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 pull request 操作关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | 在 pull request review 事件中会出现。 |
#### `pull_request_comment`
当 pull request 时间线评论被创建、编辑或删除时,会触发此事件。
**动作类型:** `created``edited``deleted`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 评论操作类型。 |
| `issue` | `object` | **必填。** 与该 pull request 关联的 issue 记录。 |
| `pull_request` | `object` | **必填。** 评论所属的 pull request。 |
| `comment` | `object` | **必填。** 被创建、编辑或删除的评论。 |
| `changes` | `object` | 可选。当操作类型为 `edited` 时,表示评论正文的旧值。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `is_pull` | `boolean` | **必填。** 对此事件来说始终为 `true`。 |
#### `pull_request_review`
这是 Webhook 设置界面中的一个仅用于订阅的汇总事件。
它不会生成独立的投递 payload。勾选后Gitea 实际投递的是更具体的
`pull_request_review_approved``pull_request_review_rejected`
`pull_request_review_comment` 事件。
#### `pull_request_review_approved`
当 pull request review 以批准形式提交时,会触发此事件。
**动作类型:** `reviewed`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 始终为 `reviewed`。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被评审的 pull request。 |
| `requested_reviewer` | `object` | 在评审请求事件中会出现。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 提交该评审的用户。 |
| `commit_id` | `string` | 与该评审事件关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | **必填。** 评审负载。对此事件,`review.type``approved`。 |
#### `pull_request_review_rejected`
当 pull request review 以拒绝或请求修改的形式提交时,会触发此事件。
**动作类型:** `reviewed`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 始终为 `reviewed`。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被评审的 pull request。 |
| `requested_reviewer` | `object` | 在评审请求事件中会出现。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 提交该评审的用户。 |
| `commit_id` | `string` | 与该评审事件关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | **必填。** 评审负载。对此事件,`review.type``rejected`。 |
#### `pull_request_review_comment`
当 pull request review 以评论形式提交时,会触发此事件。
**动作类型:** `reviewed`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 始终为 `reviewed`。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被评审的 pull request。 |
| `requested_reviewer` | `object` | 在评审请求事件中会出现。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 提交该评审的用户。 |
| `commit_id` | `string` | 与该评审事件关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | **必填。** 评审负载。对此事件,`review.type``comment`。 |
#### `pull_request_sync`
当新的提交被推送后pull request 被同步时,会触发此事件。
**动作类型:** `synchronized`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 始终为 `synchronized`。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被同步的 pull request。 |
| `requested_reviewer` | `object` | 在评审请求事件中会出现。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 执行同步操作的用户。 |
| `commit_id` | `string` | 与该同步事件关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | 在 pull request review 事件中会出现。 |
#### `pull_request_review_request`
当请求审查者或移除审查请求时,会触发此事件。
**动作类型:** `review_requested``review_request_removed`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 评审请求操作类型。 |
| `number` | `integer` | **必填。** Pull request 编号。 |
| `changes` | `object` | 可选。编辑字段之前的值,或标签变化明细。 |
| `pull_request` | `object` | **必填。** 被操作的 pull request。 |
| `requested_reviewer` | `object` | 被请求或被移除的评审者。 |
| `repository` | `object` | **必填。** 包含该 pull request 的仓库。 |
| `sender` | `object` | **必填。** 执行该操作的用户。 |
| `commit_id` | `string` | 与该 pull request 操作关联的提交 SHA如果适用则会出现。 |
| `review` | `object` | 在 pull request review 事件中会出现。 |
### 工作流事件
- `workflow_run``workflow_job`
#### `workflow_run`
当 Gitea Actions 工作流运行状态发生变化时,会触发此事件。
**动作类型:** `queued``waiting``in_progress``completed`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 工作流运行状态变化。 |
| `workflow` | `object` | **必填。** 工作流定义。 |
| `workflow_run` | `object` | **必填。** 被操作的工作流运行记录。 |
| `pull_request` | `object` | 当该工作流运行与某个 pull request 相关时会出现。 |
| `organization` | `object` | 当仓库所有者是组织时会出现。 |
| `repository` | `object` | **必填。** 包含该工作流的仓库。 |
| `sender` | `object` | **必填。** 触发该工作流运行更新的用户。 |
#### `workflow_job`
当 Gitea Actions 工作流任务状态发生变化时,会触发此事件。
**动作类型:** `queued``waiting``in_progress``completed`
##### Payload 参数
| 名称 | 类型 | 说明 |
| --- | --- | --- |
| `action` | `string` | **必填。** 工作流任务状态变化。 |
| `workflow_job` | `object` | **必填。** 被操作的工作流任务。 |
| `pull_request` | `object` | 当该工作流任务与某个 pull request 相关时会出现。 |
| `organization` | `object` | 当仓库所有者是组织时会出现。 |
| `repository` | `object` | **必填。** 包含该工作流任务的仓库。 |
| `sender` | `object` | **必填。** 触发该工作流任务更新的用户。 |
## 测试、最近投递与重放
每个 Webhook 页面都包含:
- `Test Delivery`:会向仓库发送一次模拟的 `push` 事件。
- `Recent Deliveries`:显示请求和响应详情。
- `Redelivery`:重新投递一次历史 Webhook 记录。
如果仓库还没有任何提交,测试投递会使用一个生成的假提交,以便仍然可以测试
Webhook。
## 管理说明
管理员还可以通过实例级设置控制 Webhook 投递,例如主机允许列表、投递超时和
清理策略。详见
[配置速查表中的 Webhook 小节](../../administration/config-cheat-sheet.md#webhook-webhook)。