GitHub

为什么需要"订阅 Release"这件事如果你维护过任何"部署在服务器上、却由第三方持续迭代"的软件，一定经历过这种时刻： 某个插件修了一个你踩过的 bug，但你不知道，还在用老版本 你手动执行升级，结果升级把本地补丁冲掉了，功能悄悄变坏 你配了 GitHub Watch 邮件通知，但邮件太多，根本没在看 我自己的服务器上就有三个这样的"受害者"： 目标 性质 痛点 sz-metro-api（深圳地铁 API 服务） 我自己的仓库 每次 push 都要手动 SSH 上去 pull + 编译 + 重启 Hermes Agent（AI Agent 框架） 别人的仓库（NousResearch） 有新版本不知道；而且本地有 patch，更新会重置 hermes-feishu-streaming-card（飞书卡片插件） 别人的仓库（baileyh8） 三天连发 4 个小版本，全靠手动检查 三者的共同问题：版本更新如何被自动感知、并自动执行后续动作（部署/升级/通知）？ 本文不打算只讲某一个具体方案，而是给出一个可复用的方法论：GitHub Release 自动化更新有三条路径，各自适用什么场景、有什么坑，以及如何用一张决策树快速选型。三个真实案例（上面的三个目标）就是这套方法论的实践样本。 核心决策框架：三个维度任何"订阅 Release"的需求，都可以用三个维度来定位： 维度 1：仓库是不是自己的？——决定技术上能不能用 WebhookGitHub 的 Webhook 只有仓库管理员（owner 或 admin 权限的协作者）能配置。这是最硬性的约束： 自己的仓库 → 原生 Webhook 可用（实时、官方、零轮询成本） 别人的仓库 → GitHub 不会给你推事件，只能轮询（Argus / Cron） 维度 2：更新敏感度？——决定要不要全自动执行 敏感（改代码、重启核心服务、有本地 patch 要维护）→ 需要可控的自动执行 + 失败可见 不敏感（换个包、重启个 sidecar）→ 简单自动即可，甚至只需要通知 维度 3：实时性要求？——决定轮询周期和架构复杂度 秒级响应（CI/CD 链路）→ Webhook 分钟级（第三方工具的版本跟进）→ Argus（30 分钟轮询） 小时/天级（低优先级的检查）→ Cron 决策树 flowchart TD Q1{"仓库是自己的？"} Q1 -- "是" --> A["方案一：原生 Webhook实时推送 release/push 事件配 HMAC 签名验证"] Q1 -- "否" --> Q2{"更新敏感（需补丁恢复、失败可见）或需要统一看板?"} Q2 -- "是" --> B["方案二：Argus 轮询 + Webhook 转发监控器查 GitHub API发现新版主动发 Webhook 给你"] Q2 -- "否" --> C["方案三：Cron 定期检查脚本 curl 对比版本有变化才动作，无变化静默"] 一句话版本：自己的仓库用 Webhook，别人的仓库里"重要"的用 Argus、“无所谓"的用 Cron。 ...