企业官网建设流程全解析

Automatisch 集成 Gitea 触发器指南：用轮询触发 Issue、Pull Request、Star 与 Watch 事件

【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch

本指南基于 Automatisch 开源项目（GitHub 上备受欢迎的开源 Zapier 替代方案）中 Gitea 应用的官方文档与真实源码，系统讲解如何在 Automatisch 工作流中使用 Gitea 的四个内置触发器——New issues、New pull requests、New stargazers、New watchers。读完本文，你将掌握每个触发器的功能、可配置参数、底层轮询实现原理（含分页逻辑与幂等去重机制），并能够独立搭建"仓库动态 → 自动化动作"的工作流。

一、Gitea 触发器概览

Automatisch 的 Gitea 应用通过**轮询（polling）**方式监听仓库动态，共提供四个触发器，定义于 triggers/index.js，与官方文档 triggers.md 一一对应：

四个触发器全部声明了pollInterval: 15，即每 15 分钟检查一次对应 API 端点。根据 define-trigger.js 的校验逻辑，触发器必须带有pollInterval或声明为 webhook 类型才能通过定义校验，Gitea 这四个触发器均属于轮询型（polling trigger），无需在 Gitea 侧配置 Webhook，仅依赖 API 轮询即可工作。

二、前置条件：建立 Gitea 连接

在使用任何触发器之前，必须先完成 Gitea OAuth2 连接配置，完整步骤见 connection.md：

1. 登录你的 Gitea 实例，进入Settings（设置）面板；
2. 点击Applications（应用）按钮；
3. 在Manage OAuth2 Applications区域创建一个新的 OAuth2 应用；
4. 将 Automatisch 提供的OAuth Redirect URL复制到 Gitea 的Redirect URIs字段（每个 URI 单独占一行）；
5. 将 Gitea 生成的Client ID填入 Automatisch；
6. 将 Gitea 生成的Client Secret填入 Automatisch；
7. 在 Automatisch 的Instance URL字段填写你的 Gitea 实例地址；
8. 点击Submit提交，完成连接创建。

连接所需的字段定义在 auth/index.js：

• oAuthRedirectUrl：只读字段，固定值为{WEB_APP_URL}/app/gitea/connections/add，可一键复制；
• instanceUrl：必填，你的 Gitea 实例地址（支持 Gitea.com 或自托管实例）；
• clientId/clientSecret：必填，来自 Gitea 的 OAuth2 应用。

instanceUrl之所以关键，是因为 set-base-url.js 会在每个请求发出前把baseURL动态设置为${instanceUrl}/api/v1，所有触发器与动态数据的 API 调用都基于该地址。授权流程由 generate-auth-url.js 实现：构造{instanceUrl}/login/oauth/authorize授权链接（含client_id、redirect_uri、response_type=code与随机state），并将原始 state 保存用于后续校验。

三、New issues：新 Issue 触发

触发条件：指定的 Gitea 仓库中创建了新 Issue（new-issues/index.js）。

该触发器提供三个配置参数：

• Repo（必选）：下拉框，动态加载当前用户可见的仓库列表，数据源来自动态数据listRepos（见下文"动态数据支持"）；
• Which types of issues should this trigger on?（必选）：Issue 状态过滤，默认值为all，可选closed、open、all；
• Labels（可选）：动态字段，可为每个 Label 再次打开下拉框，从指定仓库的标签列表中选择；只有被添加了所选标签的 Issue 才会触发。底层会把这些标签以逗号连接后作为 API 的labels查询参数传递。

触发运行时，先读取$.step.parameters中的repo、issueType、labels，并从$.auth.data.repoOwner取出仓库属主，然后分页请求GET /repos/{repoOwner}/{repo}/issues，查询参数包含state（状态过滤）与labels（标签过滤）。

四、New pull requests：新 Pull Request 触发

触发条件：用户创建了新的 Pull Request（new-pull-requests/index.js）。

配置参数：

• Repo（必选）：同 New issues，动态加载仓库列表；
• Which types of pulls should this trigger on?（可选）：PR 状态过滤，默认all，可选closed、open、all；
• Type of Sort?（可选）：排序方式，默认all，可选oldest、recentupdate、leastupdate、mostcomment、leastcomment、priority。

触发运行时请求GET /repos/{repoOwner}/{repo}/pulls，查询参数为sort（排序）与state（状态），同样采用分页拉取全部结果。

五、New stargazers 与 New watchers：Star 与 Watch 事件触发

New stargazers（new-stargazers/index.js）：当有用户给仓库点 Star 时触发，仅需选择Repo（必选），运行时请求GET /repos/{repoOwner}/{repo}/stargazers。

New watchers（new-watchers/index.js）：当有用户 Watch（订阅）仓库时触发，仅需选择Repo（必选），运行时请求GET /repos/{repoOwner}/{repo}/subscribers（Gitea 将订阅者视为 watch 用户）。

两个触发器返回的每一条数据都会通过$.pushTriggerItem推入执行流，raw 数据为 Gitea API 返回的用户对象，internalId取id字段字符串，用于事件去重。

六、底层实现机制：轮询、分页与去重

四个触发器的run($)函数采用完全一致的轮询模式，核心流程如下（以 New issues 为例）：

const params = { page: 1, limit: 100, state: issueType, labels: formattedAllLabels }; let totalCount; let totalRequestedCount; do { const { data, headers } = await $.http.get(`/repos/${repoOwner}/${repo}/issues`, { params }); params.page = params.page + 1; totalCount = Number(headers['x-total-count']); totalRequestedCount = params.page * params.limit; if (data?.length) { for (const issue of data) { $.pushTriggerItem({ raw: issue, meta: { internalId: issue.id.toString() } }); } } } while (totalRequestedCount <= totalCount);

值得注意的实现细节：

1. 分页拉全量：单页上限limit: 100，通过 Gitea 响应头x-total-count判断总条数，循环递增page直至拉完全部数据，避免遗漏历史事件；
2. 幂等去重：internalId取自 Gitea 数据的id，Automatisch 会依据该 ID 跳过已处理过的事件，因此即使轮询间隔内产生多条数据也不会重复触发；
3. 轮询频率：pollInterval: 15表示每 15 分钟执行一次检查，属于近实时触发，无法做到秒级即时响应，适合对时效性要求不高的场景。

七、配套动态数据支持

触发器中的仓库下拉框由动态数据listRepos提供（list-repos/index.js）：分页请求GET /user/repos，将当前连接用户可见的仓库以{ value: repo.name, name: repo.name }形式返回为下拉选项。

New issues 的 Labels 动态字段依赖listLabels（list-labels/index.js）：请求GET /repos/{repoOwner}/{repo}/labels，依据showLabelId参数决定下拉值使用标签 ID 还是名称。listRepos与listLabels均由应用定义文件 index.js 挂载到dynamicData集合，触发器通过getDynamicData查询机制动态引用。

八、实战：搭建"新 Issue → 自动通知"工作流

综合上述能力，一个典型的使用场景是：Gitea 仓库出现新 Issue 时，自动发送通知。

1. 在 Automatisch 中新建 Flow，添加Gitea → New issues触发器；
2. 下拉选择要监听的仓库；
3. 按需设置 Issue 状态（如open）与标签过滤；
4. 连接后续动作步骤，例如使用 SMTP 或 Slack 等应用发送告警；
5. 触发器每 15 分钟检查一次，新 Issue 会作为触发数据进入下游步骤，可直接引用 Issue 的标题、编号、创建人等字段。

同理，将触发器替换为 New pull requests、New stargazers 或 New watchers，即可分别实现 PR 提醒、Star 播报与 Watch 统计等自动化。

九、适用范围与限制

• 触发器依赖 OAuth2 连接，且请求目标为instanceUrl对应的 Gitea 实例 API（/api/v1），自托管 Gitea 与 Gitea.com 均可使用；
• 触发方式为轮询而非 Webhook，存在最长 15 分钟的延迟，不适用于需要即时响应的场景；
• 若 Gitea 实例不可达或 Token 失效，轮询将失败，请通过连接的重新授权（refresh-token 逻辑）恢复。

上述实现细节均可在仓库中验证：触发器定义位于 packages/backend/src/apps/gitea/triggers/，连接配置说明见 packages/docs/pages/apps/gitea/connection.md，官方触发器清单见 packages/docs/pages/apps/gitea/triggers.md。

【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch