Automatisch 的 GitHub 触发器全解析5 大触发方式与源码级工作原理【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatischAutomatisch 是一款开源的 Zapier 替代方案内置了完整的 GitHub 集成应用。本文基于仓库中 GitHub 应用的触发器文档triggers.md逐一解析 Automatisch 为 GitHub 提供的 5 种触发器——新建 Issue、新建 Pull Request、Pull Request 事件、新 Star、新 Watch——并深入其源码packages/backend/src/apps/github/triggers说明轮询polling与 Webhook 两种触发机制的底层实现、参数配置与去重逻辑。读完本文你将掌握如何在实际工作流中选择和配置正确的 GitHub 触发器并能理解 Automatisch 触发器框架的运行原理。触发器总览根据官方文档 triggers.mdGitHub 应用共提供 5 个触发器触发器名称官方描述触发机制New issues有新 Issue 创建时触发轮询pollingNew pull requests有新 Pull Request 创建时触发轮询pollingNew pull request event在 Pull Request Webhook 事件上触发WebhookNew stargazers有用户 Star 仓库时触发轮询pollingNew watchers有用户 Watch 仓库时触发轮询polling在源码层面这 5 个触发器被统一注册在 triggers/index.js它们由 Automatisch 的defineTrigger辅助函数定义见 define-trigger.js。其中 4 个为轮询型触发器通过定时调用 GitHub REST API 拉取数据只有 New pull request event 是 Webhook 型触发器依赖 GitHub 主动推送事件。前置条件创建 GitHub 连接所有触发器都依赖一个已通过 OAuth 认证的 GitHub 连接。配置步骤见官方文档 connection.md前往 GitHub 的 OAuth 应用注册页面注册一个新的OAuth application填写Application name与Homepage URL将 Automatisch 提供的OAuth Redirect URL复制到 GitHub 页面的Authorization callback URL字段点击Register application完成注册将 GitHub 页面显示的Client ID填入 Automatisch 的Client ID字段点击Generate a new client secret生成并复制密钥填入 Automatisch 的Client Secret字段在 Automatisch 点击Submit提交连接至此即可在流程中使用 GitHub 触发器。OAuth 认证实现可参考 auth/generate-auth-url.js 与 auth/verify-credentials.js。连接建立后触发器发出的所有请求都会携带 OAuth 令牌见 common/add-auth-header.js并以当前登录用户的名义调用 GitHub API。New issues新 Issue 触发器官方描述有新 Issue 创建时触发。这是 5 个触发器中参数配置最丰富的轮询触发器其定义位于 new-issues/index.js。参数说明参数是否必填类型说明Repo否下拉框动态数据要监听的仓库数据来自listRepos动态数据源不填则监听当前用户可见的所有仓库Which types of issues should this trigger on?是下拉框过滤 Issue 范围默认all可选项all任何可见 Issue、assigned分配给自己的、created自己创建的、mentioned提及自己的、subscribed自己订阅的Label否下拉框动态数据仅当添加了该标签时触发该参数dependsOn: [parameters.repo]其选项来自listLabels动态数据源会随所选仓库动态加载这里有一个值得注意的细节Repo参数虽然可空但Label参数依赖parameters.repo才能加载标签列表。若仓库为空标签下拉框将无法提供有效选项。底层实现核心轮询逻辑位于 new-issues/new-issues.js接口路径动态化通过getRepoOwnerAndRepo见 common/get-repo-owner-and-repo.js将owner/repo格式的仓库名拆分。若同时存在 owner 与 repo则请求/repos/{owner}/{repo}/issues否则请求/issues即当前用户可见的全部 Issue查询参数labels取参数label的值filter固定为allstate固定为all因此已关闭的 Issue 也会被拉取sort为createddirection为descper_page为 100全量分页拉取利用 GitHub 响应头中的Link头进行分页通过parseLinkHeader见 helpers/parse-header-link.js解析links.next循环直至拉完所有页去重与输出每条数据以issue.id字符串作为internalId写入meta。Automatisch 的轮询框架正是依赖这个internalId来判断“是否是新数据”从而保证每条 Issue 只被处理一次。动态数据源listRepos 与 listLabels两个下拉框的数据来自 dynamic-data/index.js 注册的listRepos与listLabelslist-repos/index.js 请求/user/repos借助 common/paginate-all.js 分页聚合后把每个仓库映射为{ value: full_name, name: full_name }即下拉框选项就是owner/repo格式list-labels/index.js 则基于所选仓库拉取其标签列表。New pull requests新 Pull Request 触发器官方描述有新 Pull Request 创建时触发。定义位于 new-pull-requests/index.js。与 New issues 相比该触发器只有一个必填参数Repo同样来自listRepos动态数据源不再支持按类型或标签过滤。核心逻辑 new-pull-requests/new-pull-requests.js 的实现要点若未设置仓库会直接抛出错误A repo must be set!固定请求/repos/{owner}/{repo}/pulls查询参数state: all、sort: created、direction: desc、per_page: 100同样通过Link头分页遍历所有结果以pullRequest.id字符串作为internalId实现去重。New pull request eventPull Request 事件触发器Webhook官方描述在 Pull Request Webhook 事件上触发。这是 GitHub 应用中唯一的 Webhook 型触发器定义位于 new-pull-request-event/index.js。与轮询触发器的本质区别Webhook 触发器不再定时轮询而是由 GitHub 在事件发生时实时推送延迟更低。其生命周期由三个方法构成registerHook创建流程并保存后Automatisch 会自动向 GitHub 发送POST /repos/{owner}/{repo}/hooks注册一个 Webhook。订阅载荷中包含events: [pull_request]config里指定了回调地址$.webhookUrl、content_type: json、insecure_ssl: 0并用appConfig.webhookSecretKey见 config/app.js作为签名密钥。注册成功后调用$.flow.setRemoteWebhookId(data.id.toString())保存远端 Webhook IDrun收到 GitHub 推送时将$.request.body即完整的 Webhook 载荷作为raw输出并用Crypto.randomUUID()生成随机internalId。由于每次事件都是新的 UUID因此每次事件都会被当作新数据触发——这正是事件型触发的预期行为unregisterHook流程被删除或停用时调用DELETE /repos/{owner}/{repo}/hooks/{remoteWebhookId}清理远端钩子避免遗留僵尸 Webhook。内置测试数据该触发器还实现了testRun若有历史执行记录则回放上一步的dataOut否则推送一段结构完整的示例数据包含action: opened、number、pull_request、repository等字段方便你在正式运行前预览字段结构、编排后续动作。Webhook 触发器的通用生命周期实现可参考 Automatisch 框架层源码 engine/trigger 及 helpers/define-trigger.js。New stargazers新 Star 触发器官方描述有用户 Star 仓库时触发。定义位于 new-stargazers/index.js必填参数为Repo。核心逻辑 new-stargazers/new-stargazers.js 有两个值得关注的实现细节使用自定义媒体类型请求/repos/{owner}/{repo}/stargazers时设置请求头Accept: application/vnd.github.starjson。这是因为只有携带该媒体类型GitHub API 才会在返回中附带starred_at字段Star 发生时间否则只能拿到用户列表而无法得知时间以时间戳去重每条 Star 记录取starred_at并借助luxon的DateTime.fromISO(...).toMillis()转换为毫秒时间戳作为internalId。因为同一个用户对同一仓库通常只会 Star 一次以时间戳为 ID 天然避免了重复触发raw字段则直接输出用户对象。分页方面采用了“先取最后一页再逐页向前回退”的策略首次请求后通过Link头的last定位到最后一页再通过prev反向遍历并reverse()数据从而实现按时间正序处理。New watchers新 Watch 触发器官方描述有用户 Watch 仓库时触发。定义位于 new-watchers/index.js必填参数同样为Repo。核心逻辑 new-watchers/new-watchers.js 与 stargazers 高度相似请求/repos/{owner}/{repo}/subscribers注意不是/watchersGitHub 将 watchers 列表托管在 subscribers 接口下per_page为 100采用同样的“取末页反向遍历 reverse()”策略保证时间正序以watcher.id.toString()作为internalId去重与 stargazers 不同它不需要特殊媒体类型头因为该接口本身就返回用户对象列表。触发器选择与实战建议在 Automatisch 中编排 GitHub 相关流程时可以按以下原则选择触发器关注 PR 的完整生命周期opened、closed、merged、review_requested 等时优先使用New pull request eventWebhook 触发器——它是实时推送且raw载荷中带有action字段后续步骤可以根据 action 值做分支判断只需要“新创建的 PR”这一条事件时使用New pull requests轮询触发器即可配置更简单监控 Issue 流入时使用New issues并善用issueType与Label参数缩小触发范围例如只监听带bug标签的 Issue、只监听分配给自己的 Issue减少无效执行做社区运营或数据统计如新增 Star 提醒、新 Watch 用户欢迎消息时使用New stargazers/New watchers。需要留意的是轮询触发器的pollInterval为 15定义于各触发器defineTrigger的pollInterval: 15字段即 Automatisch 每隔 15 分钟拉取一次数据因此从事件发生到流程执行会有最长约 15 分钟的延迟对延迟敏感的场景应改用 Webhook 型触发器。另外轮询逻辑依赖internalId去重各触发器已分别用 Issue/PR 的id、Star 时间戳、Watcher 的id实现了这一机制用户在配置阶段无需关心。小结Automatisch 的 GitHub 应用通过 5 个触发器覆盖了 Issue、Pull Request、Star、Watch 四大高频自动化场景兼具 4 个轮询触发器与 1 个 Webhook 实时触发器。从源码看其轮询触发器围绕getRepoOwnerAndRepo解析仓库名、parseLinkHeader处理分页、internalId实现去重三条主线构建Webhook 触发器则完整实现了注册、接收、注销的钩子生命周期并内置可预览的示例数据。理解这些底层机制有助于你在实际流程编排中做出更准确的触发器选型与参数配置。【免费下载链接】automatischThe open source Zapier alternative. Build workflow automation without spending time and money.项目地址: https://gitcode.com/GitHub_Trending/au/automatisch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考