ClawHub

ci-package-deploy-notify

Other

仅当用户明确要求触发 Jenkins 打包/部署，并在成功后发送飞书部署提醒时使用。适用于用户明确点名要打包某些服务、选择环境或分支、等待构建完成后通知部署的场景。模型只负责决定参数，实际执行必须调用本 skill 自带脚本。

Install

openclaw skills install ci-package-deploy-notify

ci-package-deploy-notify

把“触发打包/部署 + 成功后发飞书通知”的流程交给固定脚本处理；不要让模型自己临时拼 Jenkins 或飞书请求。

何时使用

只有当用户明确要求“现在触发打包 / 触发部署 / 发部署提醒”时才使用。

当用户表达这些意图时使用：

  • 明确要求触发某些服务打包
  • 明确要求触发 Jenkins CI / CI/CD
  • 明确要求打包完成后发部署提醒
  • 明确要求构建完成后发打包通知
  • 明确要求打包并部署 / 直接部署
  • 明确指定环境、服务、改动说明，并要求通知 SQA / 部署群

以下情况不要触发本 skill：

  • 只是讨论发版方案、发布时间、部署流程
  • 只是查询构建状态 / Jenkins 状态 / 是否发过版
  • 只是记录发版信息到文档 / 表格 / sheet
  • 只是提到“发布/部署/发版”这些词，但没有明确要求“现在执行”
  • 只是询问“能不能打包/能不能部署/这个 skill 是干什么的”

模型职责

模型只做这些事：

  1. 先判断用户是不是在明确要求立即执行；不是的话不要触发
  2. 提取服务/仓库列表
  3. 判断环境或分支（如 dev / test / demo / sit）
  4. 判断 job 类型（ci / cd）
  5. 提取改动说明 changes
  6. 如有需要，决定要 @ 的同事名
  7. 根据用户意图选择执行链路：
    • 用户说“打包通知部署 / 打包后通知测试部署” → 走 ci
    • 用户说“打包并部署 / 直接部署” → 默认走 cd，即 复用 CI job + AUTO_CD=true
    • 只有在用户明确要求“单独部署”时，才走独立 CD job
  8. 将当前会话里真实发起人的 Feishu 标识透传给脚本：优先使用当前消息发送者的 open_id（通常就是会话元数据里的 sender_id / open_id），拿不到时才回退 user_id 或配置里的默认发起人
  9. 调用固定脚本
  10. 回报结果或错误

模型不要：

  • 自己调用 Jenkins API
  • 自己构造飞书卡片
  • 自己重写等待/轮询逻辑
  • 在回复里暴露 token / webhook / secret

执行方式

脚本路径：scripts/ci_package_deploy_notify.py

基础调用：

python3 <skill_dir>/scripts/ci_package_deploy_notify.py \
  --repos cloud-mall cloud-device \
  --branch test \
  --changes "修复支付回调" \
  --initiator-id "ou_xxx" \
  --initiator-name "张三"

触发 CI/CD：

python3 <skill_dir>/scripts/ci_package_deploy_notify.py \
  --repos cloud-mall \
  --branch demo \
  --job-type cd \
  --changes "联调完成" \
  --initiator-id "ou_xxx" \
  --initiator-name "张三"

说明：

  • job-type=ci 时：只触发 CI，成功后发送 打包通知 卡片，语义是“已经打包完成，请按需部署”
  • job-type=cd 时：默认复用 CI job，并通过 AUTO_CD=true 继续部署，成功后发送 部署通知 卡片
  • CD 触发方式支持两种：
    • 默认模式：复用 CI job，通过 AUTO_CD=true 继续部署
    • 单独部署模式：仅在明确需要“单独部署”时，才使用独立 CD job，并通过 PROJECTS 等参数选择服务
  • 两种卡片都会带上服务、环境/分支、改动说明、发起人、SQA 信息

指定 @ 成员：

python3 <skill_dir>/scripts/ci_package_deploy_notify.py \
  --repos cloud-mall cloud-device \
  --branch test \
  --changes "发布完成" \
  --at Felix,Zack \
  --initiator-id "ou_xxx" \
  --initiator-name "张三"

参数整理规则

  • --repos：直接使用 config.json 里的仓库键名
  • --branch：优先由用户明确指定；当前 skill 只支持 dev / test / demo / sit，不支持 prod / master
  • --job-type：默认 ci
    • 用户说“打包通知部署 / 打包后通知测试部署”时，用 ci
    • 用户说“打包并部署 / 直接部署”时，用 cd
  • 当前默认 CD 走 AUTO_CD=true 这条链路；只有用户明确要求“单独部署”时，才切到独立 CD job。不要让模型自己拼 job 参数
  • --changes：必须提供；若用户没说，先追问一次
  • --at：可选，多个名字用逗号分隔；脚本会优先精确匹配，再做包含匹配和模糊匹配，尽量容忍拼写不准，但如果同时匹配到多个候选会直接报错要求明确
  • --initiator-id：默认传当前消息发送者的 open_id；在 Feishu 会话里，优先取会话元数据中的 sender_id / open_id，只有拿不到时才退回 user_id
  • --initiator-name：可选；如果会话里拿不到可读姓名，可以不传，不要为了补名字阻塞执行
  • 若未传 --initiator-id，脚本才会回退到配置中的默认发起人；因此正常调用时应始终透传当前真实发起人的 open_id
  • 若用户只是“咨询能不能做”或“问怎么打包”，不要自行补参数后直接执行
  • 若缺少 repos / branch / changes 中任一关键参数，先追问，不要半猜测执行

输出说明

脚本会按顺序执行：

  1. 触发前先检查 Jenkins 队列 / 正在运行的同 job、同分支、同 job_type 任务
  2. 若已存在相同参数任务，则跳过重复触发并直接等待现有任务完成
  3. 否则触发 Jenkins job
  4. 轮询 Jenkins 队列/构建状态
  5. 全部成功后发送飞书部署提醒
  6. 输出最终结果

成功时重点汇报：

  • 哪些服务触发成功
  • 是否命中“重复触发防重”并复用已有 queue/build
  • CI 是否完成
  • 若用户要求部署，AUTO_CD 链路是否完成；若明确走单独部署场景，再看独立 CD job 是否完成
  • 飞书通知是否已发送
  • 当前发送的是打包通知还是部署通知
  • 卡片中是否带上了环境/分支信息
  • 发起人是否使用了当前消息发送者的 open_id
  • SQA 是否命中模糊匹配；若匹配不明确，需直接报错并要求明确名字
  • 若未拿到当前消息发送者 open_id，是否回退到了默认发起人

失败时直接汇报失败服务和原因。 如果用户给了 prod / master，应直接报“当前 skill 不支持该环境”。

安全说明

  • 凭据来自同目录 config.json
  • 不要在聊天里复述 token / webhook / app secret / jenkins api_token

维护说明

  • 当脚本或 SKILL.md 更新后，如需让其他有权限的 agent 也拿到同一版本，使用 clawhub/技能同步流程进行发布或同步，不要只改当前工作区副本后就默认其他 agent 已生效。