# Node GitOps CI/CD（历史路径）

本文不再承载 node/lane CI/CD、GitOps 或公开入口需求规格正文。

统一规格出处是 UniDesk OA：

- [PJ2026-0106 平台运维](https://github.com/pikasTech/unidesk/blob/master/project-management/PJ2026-01/specs/PJ2026-0106-platform-ops.md)
- [PJ2026-010601 发布流水](https://github.com/pikasTech/unidesk/blob/master/project-management/PJ2026-01/specs/PJ2026-010601-controlled-release.md)
- [PJ2026-010602 源码同步](https://github.com/pikasTech/unidesk/blob/master/project-management/PJ2026-01/specs/PJ2026-010602-source-sync.md)
- [PJ2026-010603 YAML运维](https://github.com/pikasTech/unidesk/blob/master/project-management/PJ2026-01/specs/PJ2026-010603-yaml-first-ops.md)
- [PJ2026-010604 公开入口](https://github.com/pikasTech/unidesk/blob/master/project-management/PJ2026-01/specs/PJ2026-010604-public-entry.md)
- [PJ2026-010605 运维监控](https://github.com/pikasTech/unidesk/blob/master/project-management/PJ2026-01/specs/PJ2026-010605-observability-monitoring.md)

职责边界：

- 目标 node/lane 的具体实现、PipelineRun 观察和运行命令按本仓 `AGENTS.md` 与受控 CLI 执行。
- 需求边界、node/lane 规则和运维职责只更新 UniDesk OA。

## 运行参考

`scripts/gitops-render.mjs` 只保留一条 runtime lane 渲染链：

- `vNN` lane：
  - 继续使用既有版本号默认，包括 branch、catalog、namespace、runtime path、端口与 endpoint 推导。
  - 修改 renderer 时必须用同一 source commit 对比生成目录，确认既有 lane 不漂移。
- 命名 runtime lane：
  - 必须先在 `deploy/deploy.yaml` 的 `lanes.<lane>` 中声明稳定小写 id 与 node。
  - 必须显式声明 source/GitOps branch、Git read/write URL、artifact catalog、runtime path、namespace 与 image tag mode。
  - 必须显式声明 public endpoints、服务声明与 FRP 端点。
- 命名 lane 的 node：
  - 必须在 `deploy.nodes` 中声明 `gitopsRoot` 和 `sourceRepo`。
  - renderer 不从 lane 名称猜 branch、namespace、路径、端口或公开入口。
- 命名 lane 缺失 owning YAML 字段时立即失败；不得增加按具体 lane 字符串、branch 名称或端口号分支的 fallback。
- NodePort 服务只从 `lanes.<lane>.publicServices.nodes.<node>` 生成；名称、selector、service port、target port 与 node port 都由 YAML 声明。

node/lane rollout 的 120 秒阈值是性能告警和诊断分界，不是继续盲等的理由：

- `trigger-current --wait` 超过阈值或返回 pending 时，先执行定点 status。
- 使用 `hwlab nodes control-plane status --node <node> --lane <lane> --pipeline-run <name>` 查看 PipelineRun。
- 配合 `git-mirror status` 和 runtime workload 摘要判断卡点。
- 卡点范围包括 PipelineRun task、Argo sync、runtime-ready、public probe 或 git mirror flush。

只需要给 branch-follower 或 control-plane closeout 提供一轮新的真实验证源时：

- 优先使用文档、注释或等价的非运行面小 PR。
- 不把 timeout、runtime 策略或 CI/CD 逻辑改动混入验证样本。

PR 合并后如果目标分支被并行 PR 推进：

- closeout 同时记录本 PR merge commit、当前 source head 和 ancestry 证据。
- 当前 head 包含本 PR merge commit 时，后续 rollout 按当前 head 收敛，避免回滚到旧 source。
- 定点 status 只证明指定旧 PipelineRun 是否 succeeded。
- 最终用户入口验收以当前 node/lane source、GitOps revision、Argo 和 runtime 状态为准。

runtime-ready 卡住时：

- 先查看 `STATUS` 输出里的 notReady workload，再按 workload 日志和事件定位。
- 修复回到 source truth、PR、GitOps 和受控 sync/refresh。
- 不把手工 patch Deployment、裸删 Pod 或临时容器改动作为交付路径。

runtime 已 ready 但 Argo 仍 OutOfSync/Progressing 时：

- 走受控 `hwlab nodes control-plane sync|refresh --node <node> --lane <lane> --confirm` 收敛控制面。
- 再复查 bounded status。
