refactor: use git-controlled dev ci runner
This commit is contained in:
Codex
@@ -1,8 +1,8 @@
|
||||
# Code Queue Deploy
|
||||
|
||||
`bun scripts/cli.ts codex deploy <commitId>` 是旧兼容入口，现已禁用。原因是它会通过 backend-core `host.ssh` 维护通道直连 D601 部署 Code Queue，绕过 DevOps 控制面；维护通道直连 D601 现在只允许部署或修复 DevOps 本身。
|
||||
`bun scripts/cli.ts codex deploy <commitId>` 是旧兼容入口，现已禁用。原因是它会通过 backend-core `host.ssh` 维护通道直连 D601 部署 Code Queue，把维护入口扩张成第二套部署系统。
|
||||
|
||||
Code Queue 后续正式部署必须由 DevOps 控制面执行：CLI 读取 `origin/master:deploy.json#environments.dev` 或生产 desired-state 后，经 backend-core、k3sctl-adapter 和 DevOps 触发 target-side build、k3s image import、rollout、stamp 和 live commit 验证。
|
||||
Code Queue 后续正式部署必须走一条受控 target-side CD 路径：读取 `origin/master:deploy.json#environments.dev` 或生产 desired-state，在目标节点执行 source fetch、build、k3s image import、rollout、stamp 和 live commit 验证。当前阶段不提供 Code Queue CD；只提供 `ci run-dev-e2e` dev smoke runner，规则见 `docs/reference/dev-ci-runner.md`。
|
||||
|
||||
## Command
|
||||
|
||||
@@ -10,13 +10,13 @@ Code Queue 后续正式部署必须由 DevOps 控制面执行：CLI 读取 `orig
|
||||
bun scripts/cli.ts codex deploy <commitId>
|
||||
```
|
||||
|
||||
该命令必须返回结构化错误，提示改用 DevOps 控制面；不得再创建后台部署 job。`--skip-build` 不再支持。
|
||||
该命令必须返回结构化错误，说明维护通道直连 D601 部署已禁用；不得再创建后台部署 job。`--skip-build` 不再支持。
|
||||
|
||||
## Pipeline
|
||||
|
||||
历史部署 job 曾固定为以下步骤；它们现在只能作为 DevOps 控制面实现 Code Queue CD 时的目标行为，不能由 `codex deploy` 或维护通道直连触发：
|
||||
历史部署 job 曾固定为以下步骤；它们现在只能作为未来受控 Code Queue CD 的目标行为，不能由 `codex deploy` 或维护通道直连触发：
|
||||
|
||||
1. 对 Code Queue 部署先确保 PostgreSQL 中存在 `unidesk_deploy_ssh_identities(id='github.com')`，该记录保存 GitHub deploy SSH identity 的 private key、public key fingerprint 和 github.com `known_hosts` 行。DevOps 控制面不得把 secret 写入 task payload、deploy 日志、Docker image 或 Kubernetes Secret。
|
||||
1. 对 Code Queue 部署先确保 PostgreSQL 中存在 `unidesk_deploy_ssh_identities(id='github.com')`，该记录保存 GitHub deploy SSH identity 的 private key、public key fingerprint 和 github.com `known_hosts` 行。未来受控 CD 不得把 secret 写入 task payload、deploy 日志、Docker image 或 Kubernetes Secret。
|
||||
2. 在 D601 的 deploy cache 中通过本机 provider-gateway WS egress proxy 执行 `git fetch` remote，并用 `git archive <commitId>` 导出 tracked files 到一次性 export 目录；不得让 D601 直连 GitHub，也不得临时创建 SSH SOCKS、公网 master proxy 或 backend-core/provider-ingress fallback。
|
||||
3. 用 `rsync --delete` 同步导出的 repo 到 `/home/ubuntu/cq-deploy`，保留 `.state/`、`logs/`、`.git/`、`node_modules/` 和 `dist/`。
|
||||
4. 在 D601 用目标 Docker daemon 的本地 BuildKit builder 构建 `unidesk-code-queue:d601`，复用 D601 上已有基础镜像、inline cache 和 Code Queue build-base；provider-gateway WS egress 是唯一允许的构建代理通道，只作为本次 build 的环境变量与 build-arg 注入，并配合本次 build 的 `--network host` 让 RUN 阶段访问 D601 宿主 loopback proxy，不能污染 D601 宿主 Docker/HTTP proxy 配置，不能新建 SSH SOCKS、公网 master proxy 或直连 fallback。
|
||||
@@ -28,7 +28,7 @@ bun scripts/cli.ts codex deploy <commitId>
|
||||
|
||||
## Observability
|
||||
|
||||
DevOps 控制面实现 Code Queue CD 后，部署触发本身不应阻塞等待完成。返回 JSON 中必须包含 run id、status command 或等价查询入口；后台日志必须有界可查，失败时能显示最后日志尾部。
|
||||
未来受控 Code Queue CD 实现后，部署触发本身不应阻塞等待完成。返回 JSON 中必须包含 run id、status command 或等价查询入口；后台日志必须有界可查，失败时能显示最后日志尾部。
|
||||
|
||||
部署 run 到 `succeeded` 时，必须已经完成 live commit 验证。需要人工复核时可用以下命令确认 `deploy.commit`：
|
||||
|
||||
|
||||
Reference in New Issue
Block a user