docs: add g14 cicd truth sources and sop
This commit is contained in:
Codex
@@ -285,13 +285,20 @@ node scripts/dev-cloud-workbench-smoke.mjs --dom-only --url http://74.48.78.17:1
|
||||
授权凭证注入后的真实 DEV 复测：
|
||||
|
||||
```sh
|
||||
node scripts/code-agent-chat-smoke.mjs --live --url http://74.48.78.17:17666/
|
||||
node scripts/code-agent-chat-smoke.mjs --live
|
||||
node scripts/code-agent-chat-smoke.mjs --live --url http://74.48.78.17:17667/ --timeout-ms 45000
|
||||
```
|
||||
|
||||
`--live` 会向真实 DEV `/v1/agent/chat` 发送一条最小聊天请求。输出只包含
|
||||
readiness、provider/model/backend、assistant 回复是否非空和长度、错误分类等摘要；不打印
|
||||
assistant 回复正文，不读取或打印任何 Secret 值。
|
||||
|
||||
默认 `--live` 应指向当前 G14 DEV API/edge 入口 `17667`，而不是历史 D601 端口。
|
||||
健康的 Codex stdio 冷启动首个 assistant token 可能需要数十秒；10 秒级 transport
|
||||
timeout 会把健康环境误报为 transport blocker。把 timeout 提高到 45 秒左右只是在真
|
||||
实 DEV 路由上减少误报，不能替代 `completed` + 非空 assistant reply 的最终判定标
|
||||
准。
|
||||
|
||||
## 复测结果解释
|
||||
|
||||
- 若输出 `readiness.level: "BLOCKED/credential"`，后续动作是由授权路径注入
|
||||
|
||||
@@ -141,3 +141,75 @@ Argo CD 约定 repository Secret：`argocd/hwlab-git-ssh`，并带 label `argocd
|
||||
## D601 边界
|
||||
|
||||
G14 GitOps manifests 不包含 D601 kubeconfig、D601 node guard、D601 FRP 公网入口或 UniDesk Code Queue 调度入口。D601 仍由既有生产路径维护；G14 GitOps 的安装、PipelineRun、Argo sync 和 registry 操作都不能对 D601 执行 kubectl、docker 或流量切换动作。
|
||||
|
||||
## 真相源与常见误判
|
||||
|
||||
G14 PR、CI、CD 的判断应按以下顺序收敛真相，越靠前越接近最终运行面：
|
||||
|
||||
1. live runtime：目标 namespace 的 Deployment/StatefulSet template、Pod ready、`describe`、容器日志和公网 health。
|
||||
2. Argo desired state：`hwlab-g14-dev` / `hwlab-g14-prod` 的 Application revision、sync、health 和实际 runtime path。
|
||||
3. Tekton 执行证据：branch-poller 日志、PipelineRun、TaskRun results、`gitops-promote` 终态。
|
||||
4. 干净 source workspace：`origin/G14` 当前内容，以及 `npm run g14:gitops:render`、`npm run g14:gitops:check` 和 planner 输出。
|
||||
5. 对照线索：旧 commit 记忆、坏 worktree、D601 legacy 路径、脚本旧默认值，只能当线索，不能当真相。
|
||||
|
||||
常见误判与纠正：
|
||||
|
||||
- 不要把 `/root/hwlab` 当前 checkout、任意 `/tmp` worktree 或带 conflict marker 的目录当 source truth；只有跟踪 `origin/G14` 的干净 worktree 才能作为当前发布依据。
|
||||
- 不要按“某个预期 commit 是否出现在 ancestry 中”判断功能是否已经合入；当前 `origin/G14` 实际内容比历史 commit 轨迹更重要。
|
||||
- 改了 source 但没先 render/check 时，generated mismatch 只说明 source 与 generated 没对齐，不等于 Tekton 或 Argo 本身坏掉。
|
||||
- 不要把 `build-*` TaskRun 名称直接当作镜像重建证据；reuse-only 变更也会扇出同名 TaskRun，必须看 Tekton result 的 `status=reused` 与 `build-backend=reused-catalog`。
|
||||
- 不要把 `G14-gitops` 分支已更新误判成 DEV 或 PROD 已滚动；只有 Argo Application revision、目标 workload ready 和 live manifest 生效，才算 CD 真实通过。
|
||||
- 不要把 health payload 中的镜像 commit 当成 runtime manifest commit；runtime-only 修复可能复用旧镜像，只改变 probe、env、annotation 或 sidecar 行为。
|
||||
- sidecar 监听 `127.0.0.1` 时，Pod-IP `httpGet` probe 失败不等于 sidecar 自身 crash；必须同时对照 sidecar listen 日志和 probe target 语义。
|
||||
- 真实 live smoke 超时要先排除脚本入口和 timeout 误报；健康的 Codex stdio 冷启动首 token 可能需要数十秒，10 秒级 transport timeout 不能直接判服务故障。
|
||||
|
||||
## PR -> CI -> CD 最短零误判 SOP
|
||||
|
||||
1. 工作区与路由预检
|
||||
|
||||
```sh
|
||||
bun scripts/cli.ts ssh G14:/root/hwlab shell 'git status --short --branch && git remote -v | sed -n "1,4p"'
|
||||
```
|
||||
|
||||
- 只有 `/root/hwlab` 已经是 `G14...origin/G14` 时才继续；否则先从 `origin/G14` 建干净临时 worktree，再开始本轮修改。
|
||||
- k3s 只走 `G14:k3s`；不要混用 D601 kubeconfig、master server 执行面或旧 SSH route 语法。
|
||||
|
||||
2. Source / PR 预检
|
||||
|
||||
```sh
|
||||
npm run g14:gitops:render
|
||||
npm run g14:gitops:check
|
||||
node scripts/g14-ci-plan.mjs --base-ref origin/G14 --target-ref HEAD --pretty
|
||||
```
|
||||
|
||||
- 先看当前内容和长期参考，不按旧 commit 记忆判断“功能是否已合入”。
|
||||
- GitOps、manifest、poller/reconciler、provider profile 相关改动必须先跑 render/check；planner 用于判断本轮是 docs-only、reuse-only 还是需要真实构建。
|
||||
- provider/profile 变更在进入 PR 或 CI 之前，先按 `code-agent-chat-readiness.md` 做目标 Pod 最小闭环；不要把完整 CI/CD 当成 transport 试错工具。
|
||||
|
||||
3. 合并或推送到 `G14`
|
||||
|
||||
- `G14` 是 poller 的唯一 source branch。只有 source 侧检查通过后，才进入 merge 或 push。
|
||||
- push 被 fast-forward 拒绝时，先 `fetch` 和 `rebase` 到最新 `origin/G14`；不要为了抢跑 poller 强推覆盖别人的 GitOps promote 提交。
|
||||
|
||||
4. 确认 CI 已接单
|
||||
|
||||
- 先看最新 branch-poller job 或日志，确认它是否识别到新的 `G14` HEAD。
|
||||
- 再看 `hwlab-ci` 里的 PipelineRun 是否出现 `hwlab-g14-ci-poll-<short12>`。poller 还没创建 PipelineRun 时，不要先把问题归类为 Tekton 故障。
|
||||
- 如果本轮改的是 poller、Pipeline、RBAC、reconciler 或 render 模板，先确认 `hwlab-g14-control-plane-reconciler` 已经把新控制面 apply 进去，再用新 commit 验证。
|
||||
|
||||
5. 确认 CI 真实通过
|
||||
|
||||
- 最低通过条件是：`ci-json`、`plan-artifacts`、per-service fan-out、`collect-artifacts`、`gitops-promote` 全部成功。
|
||||
- `build-*` fan-out 要按 result 判断 reused 还是 rebuilt；不要只看 TaskRun 名称。
|
||||
- reuse-only 变更的目标是 `affectedServices=[]`、全部 service `status=reused`，且不触发无意义 rollout。
|
||||
|
||||
6. 确认 CD 真实通过
|
||||
|
||||
- 先确认 `G14-gitops` 头 revision 已更新，再看 Argo Application 当前 revision 是否追上该 GitOps revision。
|
||||
- 然后检查目标 namespace 的 Deployment、StatefulSet、ReplicaSet、Pod ready 和失败事件。
|
||||
- runtime-only 修复要直接检查 live Deployment template 是否带上新的 probe、env 或 annotation；不要只盯公网 health 里的镜像 commit。
|
||||
|
||||
7. 做最终运行态验证
|
||||
|
||||
- 先看公网 `/health/live`，再跑 focused live smoke；业务 smoke 必须在目标运行面已经 Healthy 后进行。
|
||||
- Code Agent 对话链路用 `node scripts/code-agent-chat-smoke.mjs --live` 或显式 `--url http://74.48.78.17:17667/ --timeout-ms 45000`；通过标准是“真实 DEV 路由 + `completed` + 非空 assistant reply”，不是单纯 HTTP 200、非 JSON chunk 或 10 秒内首包。
|
||||
|
||||
Reference in New Issue
Block a user