Code Queue Deploy

bun scripts/cli.ts codex deploy <commitId> 是旧兼容入口，现已禁用。原因是它会通过 backend-core host.ssh 维护通道直连 D601 部署 Code Queue，把维护入口扩张成第二套部署系统。

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；persistent dev apply 只支持 backend-core/frontend，规则见 docs/reference/dev-environment.md，Code Queue smoke 仍通过 ci run-dev-e2e，规则见 docs/reference/dev-ci-runner.md。

Command

bun scripts/cli.ts codex deploy <commitId>

该命令必须返回结构化错误，说明维护通道直连 D601 部署已禁用；不得再创建后台部署 job。--skip-build 不再支持。

Pipeline

历史部署 job 曾固定为以下步骤；它们现在只能作为未来受控 Code Queue CD 的目标行为，不能由 codex deploy 或维护通道直连触发：

对 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。
在 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。
用 rsync --delete 同步导出的 repo 到 /home/ubuntu/cq-deploy，保留 .state/、logs/、.git/、node_modules/ 和 dist/。
在 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。
docker save 镜像并导入原生 k3s containerd：docker save unidesk-code-queue:d601 | sudo ctr --address /run/k3s/containerd/containerd.sock -n k8s.io images import -。
kubectl apply -f src/components/microservices/k3sctl-adapter/k3s/code-queue.k8s.yaml，其中包含 Code Queue 和 d601-tcp-egress-gateway。
将解析后的 40 位 remote commit 写入 deployment/code-queue 的 CODE_QUEUE_DEPLOY_COMMIT / CODE_QUEUE_DEPLOY_REQUESTED_COMMIT，并记录到 Deployment annotation。
kubectl -n unidesk rollout restart deployment/d601-tcp-egress-gateway deployment/code-queue 并等待 rollout 完成。
通过 backend-core 的真实微服务代理读取 Code Queue /health，强制校验 deploy.commit 等于本次解析出的 remote commit；如果健康的是旧服务或旧 Pod，job 必须失败。

Observability

未来受控 Code Queue CD 实现后，部署触发本身不应阻塞等待完成。返回 JSON 中必须包含 run id、status command 或等价查询入口；后台日志必须有界可查，失败时能显示最后日志尾部。

部署 run 到 succeeded 时，必须已经完成 live commit 验证。需要人工复核时可用以下命令确认 deploy.commit：

bun scripts/cli.ts microservice health code-queue
bun scripts/cli.ts microservice proxy code-queue '/api/tasks/overview?limit=5&transcriptLimit=1&compact=1&afterSeq=0&preferId='

D601 原生 k3s 的人工诊断必须显式使用 host kubeconfig：KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl -n unidesk ...。D601 上的默认 kubectl context 可能指向 Docker Desktop 或其他本地集群，不能作为 UniDesk Code Queue 部署是否 ready 的证据。部署后直接查 k3s 时，至少确认 deployment/code-queue、code-queue-read、code-queue-write、d601-provider-egress-proxy 和 d601-tcp-egress-gateway ready，Pod 环境中的 UNIDESK_DEPLOY_REQUESTED_COMMIT/CODE_QUEUE_DEPLOY_REQUESTED_COMMIT 等于期望 commit，并且 scheduler /health 暴露 PostgreSQL ready、storage.lastError=null、egress proxy connected 和 MiniMax NO_PROXY 例外。

Boundaries

Code Queue 由 D601 k3s/k8s 控制面代管，不再通过 server rebuild、codex deploy、维护通道直连 D601 或手工 docker compose up 作为正式部署路径。Code Queue 部署必须在自身正在执行任务时仍可运行；服务重启后由 restart-recovery 恢复任务状态，不能等待当前 Code Queue task 退出后再部署。

TCP Egress Gateway

D601 k3s Pod 不能依赖主 server 公开 15432/4255 作为直连 TCP 入口；PostgreSQL 也不会自动使用 HTTP proxy 环境变量。code-queue.k8s.yaml 因此提供一个通用 d601-tcp-egress-gateway：

Pod 内业务只访问集群内 Service：d601-tcp-egress-gateway.unidesk.svc.cluster.local:15432 和 :4255。
gateway 通过 D601 provider-gateway egress proxy 的 HTTP CONNECT 转发到底层 TCP 目标。
新增 TCP 依赖时只扩展 TCP_EGRESS_ROUTES，不要在业务容器里散落公网直连地址或 ad hoc 隧道脚本。

5.4 KiB Raw Blame History Unescape Escape