19 lines
1.9 KiB
Text
19 lines
1.9 KiB
Text
# HLCC-PUSH-TO-DEPLOY-EVENT-PROTOCOL
|
||
|
||
状态：本地实现候选，尚未部署；当前现实层不得宣称可派发
|
||
|
||
语言层在冰朔明确确认“该提交需要部署”后，主动发出 `guanghu.deployment-intent/v1`。推送本身不会产生部署事件。意图必须绑定：
|
||
|
||
- 代码频道仓库、分支和完整提交 SHA；
|
||
- `REQUEST-ID@完整提交SHA` 的不可变资源；
|
||
- `deployment/requests/` 下的部署清单。
|
||
|
||
语言人格体通过 `/api/deployment/dispatch` 派发这一意图；接口要求一张单独的 `server-ops / dispatch-approved-deployment` 工单，且资源必须为同一 `REQUEST-ID@完整提交SHA`。服务端才写入 `guanghu.deployment-event/v1` 到本机队列。常驻部署 Agent 订阅此队列，读取同一提交中的清单，执行备份、部署、健康检查与回滚，并将回执回写到原工单。
|
||
|
||
没有部署意图的提交照常入库，回执为 `not_requested`；无效意图回执为 `rejected`，不会部署。推送工单绝不扩大为部署权限；服务器也不扫描仓库主动拉取部署。
|
||
|
||
`resource` 中的 `REQUEST-ID` 必须与清单文件名完全一致：`deployment/requests/<REQUEST-ID>.json`。批准 A 而执行 B 必须在派发端和常驻 Agent 端分别拒绝。
|
||
|
||
首次新单元使用 `guanghu.architecture-provision-request/v1`；已经在线的 systemd 服务必须使用 `guanghu.existing-service-update-request/v1`，先完整备份声明目标，再重启和逐项验收，失败恢复全部旧文件与旧单元。二者不得互相冒充。
|
||
|
||
当前京东节点若尚未安装 `/api/deployment/dispatch`、事件队列和常驻 worker，则先通过已有的主人邮件批准固定管理动作引导这套运行时。没有这个固定引导动作时应回执 `BOOTSTRAP_ACTION_NOT_DEPLOYED`，不得绕回人类 SSH 或云控制台，也不得发送一张服务器根本不会执行的部署工单。
|