Argus Webhook实战：触发GitHub/GitLab风格回调实现自动化部署-CSDN博客

【免费下载链接】Argus

Argus is a lightweight monitor to notify of new software releases via Gotify/Slack/other messages and/or WebHooks.

项目地址： https://gitcode.com/gh_mirrors/arg/Argus

Argus 是一个轻量级的软件发布监控工具，它会按你设定的时间间隔查询各软件的最新版本，一旦发现新版本，就能自动发送 Gotify/Slack 等消息通知，并触发 Webhook 回调——这正是本文的主角。借助 Argus Webhook，你可以在新版本发布的瞬间"伪装"出一条 GitHub/GitLab 风格的 push 回调，直接驱动 AWX、Jenkins 等 CI/CD 系统自动完成部署，全程无需人工干预。

什么是 Argus 的 Webhook 功能

先理清 Argus 的整体工作流：

监控：Argus 按配置的时间间隔轮询目标（如 GitHub Releases、Web 页面、Docker 镜像仓库等）；
发现新版本：当查询到的版本与上次不同时，触发更新动作（逻辑见 service/track.go）；
执行动作：发送 Notify 消息 + 发送 Webhook + 运行本地命令。

其中 Webhook 模块位于 webhook/ 目录，支持两种类型：

类型	`type` 值	模拟目标	发送方式
GitHub 风格	`github`	GitHub push webhook	POST JSON + 签名头
GitLab 风格	`gitlab`	GitLab webhook	POST 表单 + `token`/`ref` 参数

这个设计的巧妙之处在于：很多自动化系统（如 AWX）本身就支持"收到 GitHub webhook 就触发任务"，Argus 让你无需真的把发布流程挂到 GitHub 上，只靠版本探测就能复用现成的 webhook 入口。

三步配置 Webhook 回调

Argus 配置分为 defaults、settings、service、notify、webhook 五大块（参见 README.md），Webhook 支持"根默认值 → 服务级覆盖"的分层继承。

第 1 步：在 config.yml 中定义全局 Webhook 默认值：

webhook:
  defaults:
    type: github
    url: https://your-ci.example.com/webhook/argus
    secret: MY-SECRET
    desired_status_code: 200

第 2 步：在具体的 service 下按需覆盖（不同服务可以回调不同地址）：

service:
  myapp:
    latest_version:
      type: web
      url: https://example.com
    webhook:
      deploy-ci:
        url: https://ci.example.com/argus/myapp

第 3 步：确认服务的 dashboard 中开启了自动批准（auto_approve: true），否则新版本出现后 Argus 会在 Web UI 中等待你手动点击批准（该逻辑在 service/handlers.go）。

💡 配置可以参考官方示例 config.yml.example，修改后用 argus -config.check 打印解析后的完整配置来验证。

GitHub 风格回调：到底发了什么

当 type: github 时，Argus 会构造一条高度仿真的 push 请求（核心代码在 webhook/gets.go 与 webhook/github.go）：

请求体是一个包含 3 个字段的 JSON（定义见 webhook/header.go）：

{ "ref": "refs/heads/master", "before": "<40位随机hex>", "after": "<40位随机hex>" }

请求头则完整复刻了 GitHub 的真实头部：

X-Github-Event: push
X-Github-Delivery：UUID 格式的投递标识
X-Hub-Signature（SHA-1）与 X-Hub-Signature-256（SHA-256）：均使用你配置的 secret 对请求体做 HMAC 签名

这意味着如果你的自动化系统开启了 webhook 签名校验，只要把同样的 secret 配置到双方，Argus 的回调就能顺利通过验证——安全性和真实 GitHub 推送一致。

GitLab 风格回调：token + ref 参数

当 type: gitlab 时，行为完全不同（见 webhook/gitlab.go）：

请求以 application/x-www-form-urlencoded 方式 POST（无 JSON 体）；
在 URL 上追加 token=<secret>&ref=master 两个查询参数——这正是 GitLab 传统 webhook 的鉴权方式。

所以如果你的部署平台是 GitLab 生态（或任何接受 ?token=xxx 查询参数的服务），直接选 gitlab 类型即可，无需额外适配。

实战：新版本出现 → 自动触发部署

以 README 中提到的典型场景为例：用 Argus 监控某个项目，发现新版本后发送 GitHub 风格 Webhook 给 AWX，由 AWX 执行更新任务。整个链路是：

Argus 定时轮询 → 版本变化 → 发送签名 Webhook → AWX/CI 收到 push 事件 → 自动跑部署任务

几个让实战更顺滑的细节：

URL 和自定义头支持模板变量：url 与 headers 里可以引用当前服务的版本等信息（模板处理见 webhook/gets.go 的 GetURL），例如把版本号拼进回调 URL；
自定义请求头：通过 custom_headers（列表或 map 简写均可，解析逻辑在 webhook/header.go）为回调附加任意头；
手动补发：在 Web UI 中可以随时手动触发某个 Webhook（HandleWebhook），方便调试；
失败自动重试：发送失败后 Argus 会带退避间隔重试，max_tries 默认 3 次；且当所有 Webhook 全部成功后，Argus 才会把"已部署版本"更新为最新版本（service/handlers.go），保证状态真实。

高级参数速查表

以下参数均可在 webhook 根级、defaults 或单个 webhook 上配置，就近生效（默认值定义见 webhook/defaults.go）：

参数	默认值	说明
`type`	`github`	`github` 或 `gitlab`
`url`	—	回调地址，支持模板变量
`secret`	—	签名密钥（GitHub 签名 / GitLab token）
`desired_status_code`	`0`（即任意 2xx）	期望的响应状态码，如 `202`
`max_tries`	`3`	最大发送尝试次数
`delay`	`0s`	发送前的延迟，可等人工确认窗口
`silent_fails`	`false`	重试耗尽后是否静默（默认会通过 Notify 渠道告警）
`allow_invalid_certs`	`false`	是否允许自签名 HTTPS