Windmill Git Sync 的 GitHub App 权限升级指南Webhook 推送部署、自动 PR 与 Checks 校验【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmillWindmill 正在把原本需要你以 GitHub Action 形式运行的 git sync代码仓库 ↔ Windmill 工作区双向同步工作迁移到应用自身内部让双向同步开箱即用。本文以仓库内官方文档 docs/git-sync-github-app-permissions.md 为主体结合 docs/git-sync-pull-design.md 设计文档与后端、前端源码逐项讲解 Windmill GitHub App 新增的三项权限各自的用途、安全性边界、批准前后的行为差异以及 GitHub Enterprise ServerGHES自管理应用的配置方法帮助你在了解原理的前提下安全地完成权限升级。一、背景为什么 Windmill 的 GitHub App 需要新权限Windmill 的 Git Sync 功能负责让 Git 仓库与 Windmill 工作区保持同步脚本、流程、应用等对象既可以从工作区推送到仓库Windmill → 仓库也可以从仓库拉取部署到工作区仓库 → Windmill。过去仓库 → Windmill 这个方向并不开箱即用客户需要自己安装一个 GitHub Action在仓库中存放带有 Windmill 长期令牌token的 secret由 Action 调用wmill sync push把仓库内容推回 Windmill 实例。这带来几个问题需要手工编写并维护 workflow 文件、需要为每个仓库配置令牌、还要求 GitHub 托管的 runner 能连通客户自建实例的 URL。Windmill 正在把这项工作迁入应用本身因此 GitHub App 需要申请少量新的权限。这些权限全部限定在你安装该 App 的仓库范围内并且不会在 App 已有权限之外新增任何对你代码的访问能力——它们只是让 Windmill 能以你的身份在那些仓库上执行几类特定的 API 操作。配套的设计文档 docs/git-sync-pull-design.md 明确指出不同部署形态下「GitHub runner → 实例」「GitHub webhook → 实例」「实例 → GitHub」三条通路的可达性各不相同而「实例 → GitHub 出站」对所有人都成立把 pull 与 PR 逻辑放到实例侧正是为了在所有连通性形态下都能工作并在此基础上按可达性优雅降级可达则用 webhook 即时触发不可达则退化为轮询。二、新增的三项权限与它们各自启用的能力以下三项权限均为Read and write读写级别对应 Windmill GitHub App 的权限升级请求权限Read and write启用的能力Repository webhooks仓库 Webhooks创建 Webhook使 push 立即部署到你的 Windmill 工作区取代原先的 push-to-Windmill GitHub ActionPull requests拉取请求替你打开 promotion / fork 的拉取请求取代原先的gh pr createGitHub ActionChecks检查在拉取请求上发布 Windmill diff 检查展示这次改动会对工作区产生什么影响设计文档 docs/git-sync-pull-design.md 对这三项权限做了更细的拆解均为 write 级别Repository webhooks: write用安装令牌动态创建/删除仓库级 webhookPOST /repos/{owner}/{repo}/hooks这是 Webhook 即时同步的基础。Pull requests: write由实例侧代替你创建 promotion 与 fork 场景的 PR——这两类 PR 针对的分支wm_deploy/**与wm-fork/**本来就是 Windmill 自己推送的把「开 PR」移入部署流水线后全程只需出站连接不再依赖入站 webhook。Checks: write通过 Checks API 发布 PR 差异预览检查Windmill diff以及部署状态检查。每项能力的实际作用1. Repository webhooks —— push 即部署连接仓库后Windmill 会为每个已连接仓库创建一个专属 webhook。它会在 webhook 上自行设置事件push以及供 Checks 使用的pull_request。当仓库有 push 事件时实例校验通过后即触发对应工作区的拉取部署实现「push 即部署」替代原来的 push-to-Windmill GitHub Action。2. Pull requests —— 自动打开 promotion / fork PR在 promotion 模式或 workspace fork 场景下Windmill 的部署会推送wm_deploy/**promotion或wm-fork/**fork分支拿到 Pull requests 写权限后Windmill 会在部署完成时自动替你打开或重新打开针对目标分支的 PR替代gh pr create的 GitHub Action。3. Checks —— PR 上的 Windmill diff 检查订阅pull_request事件后Windmill 可以在 PR 打开或同步时运行一次dry_run: true的拉取预览并通过 Checks API 在 PR 上发布一个 Windmill diff 检查运行直观展示这次改动应用到工作区后会变更哪些对象——相当于把原来依赖客户 CI 的 dry-run 预览搬到 Windmill 实例侧完成。三、权限边界与安全性作用域收窄、能力最小化升级权限前需要明确三点安全边界限定在已安装仓库内。所有新权限都只作用于你安装该 App 的仓库不涉及组织级或其他仓库的任何数据。不新增代码访问。Windmill → 仓库方向一直使用 App 的Contents: write权限负责提交变更。新增的三项权限与Contents权限互不相干因此不会扩大 App 对代码内容的读写范围——webhook 只能创建/删除 hookPull requests 只能操作 PRChecks 只能读写检查运行。事件由 Windmill 按仓库设置应用级订阅列表无需改动。Windmill 为每个已连接仓库创建独立 webhook并自行设置其事件push加上用于 Checks 的pull_request。你不需要去修改 GitHub App 级别的 Subscribe to events订阅事件列表——这些事件之所以可用仅仅是因为上述权限被授予了。从实现上看backend/windmill-native-triggers/src/github/external.rs 中已有通过 GitHub REST API 创建仓库级 webhook 的先例POST /repos/{owner}/{repo}/hookspayload 携带name: web、active: true、事件列表与回调 URLgit sync 的 webhook 创建/删除复用同一套 REST 模式。而事件到达后的验签则复用 backend/windmill-trigger-http/src/http_trigger_auth.rs 中已有的 GitHub HMAC 校验逻辑读取X-Hub-Signature-256请求头去掉sha256前缀后按 SHA-256 Hex 编码比对 payload 签名。四、批准权限安全、可逆、逐项 opt-in批准是安全且可逆的权限升级请求可以在 GitHub 侧批准也可以随时在 App 安装设置中撤销每个功能都是**从工作区的 git sync 设置中逐项选择开启opt-in**的即使批准了权限不开启对应开关也不会产生任何行为变化。待批准期间一切照旧权限更新待定时现有同步和任何 GitHub Actions 工作流都保持原样继续工作Windmill → 仓库方向的提交依赖的Contents: write不受新权限影响你已安装的 push-to-Windmill /gh pr create/ dry-run 等 GitHub Action 依然可以运行尚未批准的新能力不会生效但不会破坏任何已有流程。自动 pull 开启但 webhook 权限尚未授予时如果某个仓库在 webhook 权限被授予之前就开启了自动 pullautomatically deploy changes from GitWindmill 会每隔约一分钟轮询一次被跟踪的分支设计文档中默认轮询间隔为 60 秒直到它能成功注册 webhook 为止。也就是说即时性会暂时退化为近实时但自动部署功能本身不会停摆。同理设计文档描述了一个自动化的可达性自测实例创建 webhook 后GitHub 会立即投递一次ping事件若约 10 秒内未收到实例会删除该 hook 并回退到轮询模式同时在界面上提示「实例无法从 GitHub 访问——正在使用轮询间隔 X 分钟」无需人工猜测防火墙配置。当 webhook 已激活时轮询间隔会放宽如 10 分钟作为兜底而不是完全关闭——这正是「webhook 保延迟、轮询保正确」的 ArgoCD 式模型。五、源码视角新权限背后的实现机制Webhook 创建与删除git sync 为每个仓库创建 webhook 时会为该仓库生成一个独立 secret存储在该仓库的 git-sync 设置中加密保存webhook 的回调 URL 形如{base_url}/api/w/{workspace}/github_app/webhook——该端点按工作区隔离托管 App 与自管理/GHES App 共用同一接收器。仓库断开连接或关闭自动 pull 时webhook 会被删除设置变更时重建还可以通过GET /repos/.../hooks按 URL 前缀过滤检测孤儿 hook。事件验签与路由webhook 送达后实例用存储的 secret 对X-Hub-Signature-256做 HMAC 校验复用 http_trigger_auth.rs 中mod github的Githubwebhook handler 实现校验通过后进入 reconcile协调环节。设计文档强调了一个关键安全原则webhook 与轮询都只是「提示」真正的 pull 才是权威。触发器从不携带内容只促使实例用自己的凭据把远端 HEAD 与last_synced_sha对比若分支确实移动了才入队既有的 pull 任务——因此伪造或重放的触发器最多只会产生一次廉价的空操作无法注入任何内容。循环预防Windmill 自己提交的 commit 带有[WM]前缀供 CI 忽略且 Windmill 作者bot触发的 push 事件会被跳过入队前还会对比head_sha与last_synced_shapull 任务成功后会记录已同步的 sha。三重机制确保「pull → 部署 → deployment callback → 提交 → push 事件 → 再 pull」不会形成自激循环。前端设置入口在 frontend/src/lib/components/git_sync/GitSyncRepositoryCard.svelte 中可以看到每个仓库的auto_pull设置对象mode取值auto | pollingauto表示优先尝试 webhook、失败回退轮询sync_forks默认开启且代码注释明确「只有 GitHub App 支持的仓库能注册 webhookPAT 仓库只能轮询」。仓库卡片上还会展示只读的last_pull_status最近一次同步的状态、时间、任务 id 与错误信息。需要说明的是git sync 属于 Windmill 的企业版EE能力在 backend/windmill-api/src/git_sync_oss.rs 与 backend/windmill-git-sync/src/git_sync_oss.rs 的开源实现中相关函数均为空操作占位注释注明 Git sync is an enterprise feature and not part of the open-source version完整逻辑在私有EE特性分支中实现。六、自管理应用GitHub Enterprise Server如果你使用 GitHub Enterprise ServerGHES上述功能通过自管理应用以完全相同的方式工作每次 API 调用都走应用自身的端点https://ghes-host/api/v3而不是 github.com。与托管 App 的关键差异是没有「更新待批准」这回事因为你拥有这个应用。你需要在应用设置中自行授予上述三项权限Webhooks、Pull requests、Checks均为 Read and write在安装installation上接受权限更新。入口路径为Settings → Developer settings → GitHub Apps → Permissions events。其余行为与托管 App 一致Webhook 仍按仓库逐个创建所以应用级的 Subscribe to events 列表同样无需修改你的 Windmill base URL 只需要从 GHES 主机可达而不需要暴露到公网。这在「GHES 与 Windmill 实例处于同一内网」的私有网络场景下特别实用——设计文档甚至指出这可以做到完全隔离air-gapped运行最难处理的 github.com 场景反而是 GHES 场景下最容易的。实例侧的 GHES 自管理应用配置界面位于 frontend/src/lib/components/instanceSettings/GhesAppSettings.svelte其中包含github_enterprise_app.self_managed开关、安装发现discovery与工作区分配等管理逻辑。七、与现有 CI 共存各能力的回退与迁移权限升级是一次捆绑的单次更新每次更新都会向既有安装的组织管理员重新弹出授权提示。批准前或未使用 App 的场景下各项新能力都有明确的回退路径新能力回退路径Webhook 即时同步轮询默认约 60 秒一次权限待批期间自动启用应用内自动打开 PR继续使用原有的open-pr-on-commit/open-pr-on-fork-commitworkflowPR 差异预览 / 部署状态检查无回退依赖 Checks API 与pull_request事件未授予则静默跳过纯令牌/PAT 仓库完整保留 pull 方向的轮询能力对于正在运行wmill sync push之类 GitHub Action 的老用户现有 CI 可以原样保留。触发器基于 sha 幂等重复触发无害两者天然共存。设计文档还建议若需要可后续通过 Contents API 检测到 workflow 文件后提供一键清理——但这不是迁移的前提。面向三类用户的迁移路径已安装托管 App 的用户绝大多数迁移成本仅为「追加一次增量权限授权」不需要重新连接仓库。旧权限在等待批准期间继续生效因此迁移是惰性的、永不被阻塞的若开启自动 pull 时遭遇 403权限待批界面会给出直达组织安装页的深链接引导批准并立即开始轮询用户不会卡在等待组织管理员上。未安装 App、使用令牌/SSH 凭据的用户无需批准任何权限直接开启开关即走轮询可选择性升级为「安装 Windmill GitHub App 以获得即时同步」。GHES 自管理应用用户无集中审批环节迁移就是一步——把实例 webhook URL 与生成的 secret 填入应用设置即可且通常可内网运行。参考资源均为当前仓库内文件可按需深入阅读权限说明原文docs/git-sync-github-app-permissions.md自动 pull拉取式同步完整设计docs/git-sync-pull-design.mdGitLab 同步配置参考docs/git-sync-gitlab-setup.mdGitHub webhook 创建/删除 REST 实现backend/windmill-native-triggers/src/github/external.rsGitHubX-Hub-Signature-256HMAC 校验backend/windmill-trigger-http/src/http_trigger_auth.rsGit sync 设置前端界面frontend/src/lib/components/git_sync/GitSyncRepositoryCard.svelte、frontend/src/lib/components/git_sync/GitSyncSection.svelteGHES 自管理应用设置界面frontend/src/lib/components/instanceSettings/GhesAppSettings.svelte【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Windmill Git Sync 的 GitHub App 权限升级指南：Webhook 推送部署、自动 PR 与 Checks 校验
Windmill Git Sync 的 GitHub App 权限升级指南Webhook 推送部署、自动 PR 与 Checks 校验【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmillWindmill 正在把原本需要你以 GitHub Action 形式运行的 git sync代码仓库 ↔ Windmill 工作区双向同步工作迁移到应用自身内部让双向同步开箱即用。本文以仓库内官方文档 docs/git-sync-github-app-permissions.md 为主体结合 docs/git-sync-pull-design.md 设计文档与后端、前端源码逐项讲解 Windmill GitHub App 新增的三项权限各自的用途、安全性边界、批准前后的行为差异以及 GitHub Enterprise ServerGHES自管理应用的配置方法帮助你在了解原理的前提下安全地完成权限升级。一、背景为什么 Windmill 的 GitHub App 需要新权限Windmill 的 Git Sync 功能负责让 Git 仓库与 Windmill 工作区保持同步脚本、流程、应用等对象既可以从工作区推送到仓库Windmill → 仓库也可以从仓库拉取部署到工作区仓库 → Windmill。过去仓库 → Windmill 这个方向并不开箱即用客户需要自己安装一个 GitHub Action在仓库中存放带有 Windmill 长期令牌token的 secret由 Action 调用wmill sync push把仓库内容推回 Windmill 实例。这带来几个问题需要手工编写并维护 workflow 文件、需要为每个仓库配置令牌、还要求 GitHub 托管的 runner 能连通客户自建实例的 URL。Windmill 正在把这项工作迁入应用本身因此 GitHub App 需要申请少量新的权限。这些权限全部限定在你安装该 App 的仓库范围内并且不会在 App 已有权限之外新增任何对你代码的访问能力——它们只是让 Windmill 能以你的身份在那些仓库上执行几类特定的 API 操作。配套的设计文档 docs/git-sync-pull-design.md 明确指出不同部署形态下「GitHub runner → 实例」「GitHub webhook → 实例」「实例 → GitHub」三条通路的可达性各不相同而「实例 → GitHub 出站」对所有人都成立把 pull 与 PR 逻辑放到实例侧正是为了在所有连通性形态下都能工作并在此基础上按可达性优雅降级可达则用 webhook 即时触发不可达则退化为轮询。二、新增的三项权限与它们各自启用的能力以下三项权限均为Read and write读写级别对应 Windmill GitHub App 的权限升级请求权限Read and write启用的能力Repository webhooks仓库 Webhooks创建 Webhook使 push 立即部署到你的 Windmill 工作区取代原先的 push-to-Windmill GitHub ActionPull requests拉取请求替你打开 promotion / fork 的拉取请求取代原先的gh pr createGitHub ActionChecks检查在拉取请求上发布 Windmill diff 检查展示这次改动会对工作区产生什么影响设计文档 docs/git-sync-pull-design.md 对这三项权限做了更细的拆解均为 write 级别Repository webhooks: write用安装令牌动态创建/删除仓库级 webhookPOST /repos/{owner}/{repo}/hooks这是 Webhook 即时同步的基础。Pull requests: write由实例侧代替你创建 promotion 与 fork 场景的 PR——这两类 PR 针对的分支wm_deploy/**与wm-fork/**本来就是 Windmill 自己推送的把「开 PR」移入部署流水线后全程只需出站连接不再依赖入站 webhook。Checks: write通过 Checks API 发布 PR 差异预览检查Windmill diff以及部署状态检查。每项能力的实际作用1. Repository webhooks —— push 即部署连接仓库后Windmill 会为每个已连接仓库创建一个专属 webhook。它会在 webhook 上自行设置事件push以及供 Checks 使用的pull_request。当仓库有 push 事件时实例校验通过后即触发对应工作区的拉取部署实现「push 即部署」替代原来的 push-to-Windmill GitHub Action。2. Pull requests —— 自动打开 promotion / fork PR在 promotion 模式或 workspace fork 场景下Windmill 的部署会推送wm_deploy/**promotion或wm-fork/**fork分支拿到 Pull requests 写权限后Windmill 会在部署完成时自动替你打开或重新打开针对目标分支的 PR替代gh pr create的 GitHub Action。3. Checks —— PR 上的 Windmill diff 检查订阅pull_request事件后Windmill 可以在 PR 打开或同步时运行一次dry_run: true的拉取预览并通过 Checks API 在 PR 上发布一个 Windmill diff 检查运行直观展示这次改动应用到工作区后会变更哪些对象——相当于把原来依赖客户 CI 的 dry-run 预览搬到 Windmill 实例侧完成。三、权限边界与安全性作用域收窄、能力最小化升级权限前需要明确三点安全边界限定在已安装仓库内。所有新权限都只作用于你安装该 App 的仓库不涉及组织级或其他仓库的任何数据。不新增代码访问。Windmill → 仓库方向一直使用 App 的Contents: write权限负责提交变更。新增的三项权限与Contents权限互不相干因此不会扩大 App 对代码内容的读写范围——webhook 只能创建/删除 hookPull requests 只能操作 PRChecks 只能读写检查运行。事件由 Windmill 按仓库设置应用级订阅列表无需改动。Windmill 为每个已连接仓库创建独立 webhook并自行设置其事件push加上用于 Checks 的pull_request。你不需要去修改 GitHub App 级别的 Subscribe to events订阅事件列表——这些事件之所以可用仅仅是因为上述权限被授予了。从实现上看backend/windmill-native-triggers/src/github/external.rs 中已有通过 GitHub REST API 创建仓库级 webhook 的先例POST /repos/{owner}/{repo}/hookspayload 携带name: web、active: true、事件列表与回调 URLgit sync 的 webhook 创建/删除复用同一套 REST 模式。而事件到达后的验签则复用 backend/windmill-trigger-http/src/http_trigger_auth.rs 中已有的 GitHub HMAC 校验逻辑读取X-Hub-Signature-256请求头去掉sha256前缀后按 SHA-256 Hex 编码比对 payload 签名。四、批准权限安全、可逆、逐项 opt-in批准是安全且可逆的权限升级请求可以在 GitHub 侧批准也可以随时在 App 安装设置中撤销每个功能都是**从工作区的 git sync 设置中逐项选择开启opt-in**的即使批准了权限不开启对应开关也不会产生任何行为变化。待批准期间一切照旧权限更新待定时现有同步和任何 GitHub Actions 工作流都保持原样继续工作Windmill → 仓库方向的提交依赖的Contents: write不受新权限影响你已安装的 push-to-Windmill /gh pr create/ dry-run 等 GitHub Action 依然可以运行尚未批准的新能力不会生效但不会破坏任何已有流程。自动 pull 开启但 webhook 权限尚未授予时如果某个仓库在 webhook 权限被授予之前就开启了自动 pullautomatically deploy changes from GitWindmill 会每隔约一分钟轮询一次被跟踪的分支设计文档中默认轮询间隔为 60 秒直到它能成功注册 webhook 为止。也就是说即时性会暂时退化为近实时但自动部署功能本身不会停摆。同理设计文档描述了一个自动化的可达性自测实例创建 webhook 后GitHub 会立即投递一次ping事件若约 10 秒内未收到实例会删除该 hook 并回退到轮询模式同时在界面上提示「实例无法从 GitHub 访问——正在使用轮询间隔 X 分钟」无需人工猜测防火墙配置。当 webhook 已激活时轮询间隔会放宽如 10 分钟作为兜底而不是完全关闭——这正是「webhook 保延迟、轮询保正确」的 ArgoCD 式模型。五、源码视角新权限背后的实现机制Webhook 创建与删除git sync 为每个仓库创建 webhook 时会为该仓库生成一个独立 secret存储在该仓库的 git-sync 设置中加密保存webhook 的回调 URL 形如{base_url}/api/w/{workspace}/github_app/webhook——该端点按工作区隔离托管 App 与自管理/GHES App 共用同一接收器。仓库断开连接或关闭自动 pull 时webhook 会被删除设置变更时重建还可以通过GET /repos/.../hooks按 URL 前缀过滤检测孤儿 hook。事件验签与路由webhook 送达后实例用存储的 secret 对X-Hub-Signature-256做 HMAC 校验复用 http_trigger_auth.rs 中mod github的Githubwebhook handler 实现校验通过后进入 reconcile协调环节。设计文档强调了一个关键安全原则webhook 与轮询都只是「提示」真正的 pull 才是权威。触发器从不携带内容只促使实例用自己的凭据把远端 HEAD 与last_synced_sha对比若分支确实移动了才入队既有的 pull 任务——因此伪造或重放的触发器最多只会产生一次廉价的空操作无法注入任何内容。循环预防Windmill 自己提交的 commit 带有[WM]前缀供 CI 忽略且 Windmill 作者bot触发的 push 事件会被跳过入队前还会对比head_sha与last_synced_shapull 任务成功后会记录已同步的 sha。三重机制确保「pull → 部署 → deployment callback → 提交 → push 事件 → 再 pull」不会形成自激循环。前端设置入口在 frontend/src/lib/components/git_sync/GitSyncRepositoryCard.svelte 中可以看到每个仓库的auto_pull设置对象mode取值auto | pollingauto表示优先尝试 webhook、失败回退轮询sync_forks默认开启且代码注释明确「只有 GitHub App 支持的仓库能注册 webhookPAT 仓库只能轮询」。仓库卡片上还会展示只读的last_pull_status最近一次同步的状态、时间、任务 id 与错误信息。需要说明的是git sync 属于 Windmill 的企业版EE能力在 backend/windmill-api/src/git_sync_oss.rs 与 backend/windmill-git-sync/src/git_sync_oss.rs 的开源实现中相关函数均为空操作占位注释注明 Git sync is an enterprise feature and not part of the open-source version完整逻辑在私有EE特性分支中实现。六、自管理应用GitHub Enterprise Server如果你使用 GitHub Enterprise ServerGHES上述功能通过自管理应用以完全相同的方式工作每次 API 调用都走应用自身的端点https://ghes-host/api/v3而不是 github.com。与托管 App 的关键差异是没有「更新待批准」这回事因为你拥有这个应用。你需要在应用设置中自行授予上述三项权限Webhooks、Pull requests、Checks均为 Read and write在安装installation上接受权限更新。入口路径为Settings → Developer settings → GitHub Apps → Permissions events。其余行为与托管 App 一致Webhook 仍按仓库逐个创建所以应用级的 Subscribe to events 列表同样无需修改你的 Windmill base URL 只需要从 GHES 主机可达而不需要暴露到公网。这在「GHES 与 Windmill 实例处于同一内网」的私有网络场景下特别实用——设计文档甚至指出这可以做到完全隔离air-gapped运行最难处理的 github.com 场景反而是 GHES 场景下最容易的。实例侧的 GHES 自管理应用配置界面位于 frontend/src/lib/components/instanceSettings/GhesAppSettings.svelte其中包含github_enterprise_app.self_managed开关、安装发现discovery与工作区分配等管理逻辑。七、与现有 CI 共存各能力的回退与迁移权限升级是一次捆绑的单次更新每次更新都会向既有安装的组织管理员重新弹出授权提示。批准前或未使用 App 的场景下各项新能力都有明确的回退路径新能力回退路径Webhook 即时同步轮询默认约 60 秒一次权限待批期间自动启用应用内自动打开 PR继续使用原有的open-pr-on-commit/open-pr-on-fork-commitworkflowPR 差异预览 / 部署状态检查无回退依赖 Checks API 与pull_request事件未授予则静默跳过纯令牌/PAT 仓库完整保留 pull 方向的轮询能力对于正在运行wmill sync push之类 GitHub Action 的老用户现有 CI 可以原样保留。触发器基于 sha 幂等重复触发无害两者天然共存。设计文档还建议若需要可后续通过 Contents API 检测到 workflow 文件后提供一键清理——但这不是迁移的前提。面向三类用户的迁移路径已安装托管 App 的用户绝大多数迁移成本仅为「追加一次增量权限授权」不需要重新连接仓库。旧权限在等待批准期间继续生效因此迁移是惰性的、永不被阻塞的若开启自动 pull 时遭遇 403权限待批界面会给出直达组织安装页的深链接引导批准并立即开始轮询用户不会卡在等待组织管理员上。未安装 App、使用令牌/SSH 凭据的用户无需批准任何权限直接开启开关即走轮询可选择性升级为「安装 Windmill GitHub App 以获得即时同步」。GHES 自管理应用用户无集中审批环节迁移就是一步——把实例 webhook URL 与生成的 secret 填入应用设置即可且通常可内网运行。参考资源均为当前仓库内文件可按需深入阅读权限说明原文docs/git-sync-github-app-permissions.md自动 pull拉取式同步完整设计docs/git-sync-pull-design.mdGitLab 同步配置参考docs/git-sync-gitlab-setup.mdGitHub webhook 创建/删除 REST 实现backend/windmill-native-triggers/src/github/external.rsGitHubX-Hub-Signature-256HMAC 校验backend/windmill-trigger-http/src/http_trigger_auth.rsGit sync 设置前端界面frontend/src/lib/components/git_sync/GitSyncRepositoryCard.svelte、frontend/src/lib/components/git_sync/GitSyncSection.svelteGHES 自管理应用设置界面frontend/src/lib/components/instanceSettings/GhesAppSettings.svelte【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考