mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
cb93348c29d5c9a2134a6a4739e0f1f1a83188ae
pikasTech-unidesk/.agents/skills/unidesk-cicd/SKILL.md
T
Codex f934d0b3cd feat: add cicd branch follower
2026-07-03 03:36:58 +00:00

6.1 KiB
Raw Blame History

name, description
name description
unidesk-cicd UniDesk CI/CD 控制面 — `cicd branch-follower`、`hwlab g14`、`hwlab nodes control-plane` 和 `agentrun` 子命令，覆盖自动跟随 branch、PR 监控自动合并、Tekton/Argo 控制面、git-mirror、Secret、observability、CI tools image、PipelineRun 清理、AgentRun v0.1 部署和 AgentRun YAML-only lane 部署。用户提到 CI/CD、deploy、rollout、PipelineRun、trigger、git-mirror、control-plane、k8s/k3s 部署、branch follower、自动跟随、agentrun 部署、hwlab g14、monitor-prs、trigger-current 时使用。任何需要把代码变更推送部署到 G14 k3s 的操作都必须走本 skill。

UniDesk CI/CD

HWLAB G14 和 AgentRun CI/CD 的受控入口。任何 PR 监控、Tekton/Argo、git-mirror、Secret、observability、CI tools image、PipelineRun 清理或 AgentRun 部署都必须走 bun scripts/cli.ts。

高频入口

bun scripts/cli.ts hwlab g14 monitor-prs --lane v02 --once --dry-run
bun scripts/cli.ts hwlab g14 control-plane status --lane v02
bun scripts/cli.ts hwlab g14 control-plane trigger-current --lane v02 --confirm --wait
bun scripts/cli.ts hwlab g14 git-mirror status --lane v02
bun scripts/cli.ts agentrun control-plane status
bun scripts/cli.ts cicd branch-follower status

按职责读取拆分后的 reference：

P0 边界

  • CI/CD、GitOps、rollout、PipelineRun、Argo、git-mirror 和 AgentRun 部署必须走受控 CLI；不要用裸 kubectl、argo、tkn、curl 当正式控制入口。
  • CI/CD source authority 只能来自 Kubernetes 托管的 git-mirror snapshot：受控命令先同步 GitHub refs 到 k8s git-mirror，再创建/读取不可变 refs/unidesk/snapshots/.../<commit> stage ref；build/status/publish 只消费该 snapshot，host worktree、本地 git fetch/pull、可变 branch ref 或 Pipeline 内直连 GitHub 都不能作为 authoritative source。
  • cicd branch-follower 的自动跟随全过程不得读取或挂载 host worktree、target dev dir、.worktree/* 或 local git checkout；controller pod 只能用 k8s git-mirror 和 EmptyDir 执行，状态以 K8s ConfigMap/Lease 和 adapter status 为准。
  • CI/CD、rollout、publish、image build 和部署链路禁止新引入 Docker 依赖；不得依赖 Docker socket、Docker daemon、host Docker、docker build、docker push 或等价 Docker-only 路径。
  • 正式 CI/CD、publish、image build 和 rollout 必须走 Tekton Task/Pipeline/PipelineRun 承担 CI，并通过 GitOps/Argo 承担部署收敛；普通 Kubernetes Job 只允许用于 bounded helper、source sync、diagnostic、cleanup 或 bootstrap，不得作为正式发布、镜像构建或 rollout 入口。
  • 正式 CI/CD 必须提供一键完成入口：同一受控命令应完成 source sync、构建、发布、GitOps/Argo 收敛、runtime provenance 校验和 /health 端点验证；不要要求操作者手动串联多个 publish/apply/status 命令才能完成一次交付。
  • CI/CD 一键交付的端到端 wall-clock 目标是低于 2 分钟；计时从操作者触发受控命令开始，到 runtime ready 且 /health 端点验证完成为止。具体 wait/timeout/budget 字段必须从 YAML/source-of-truth 读取并配置到满足该目标。
  • CI/CD validation 阶段只能验证部署对象的 /health 端点和必要 provenance；禁止在 CI/CD gate 中运行 web-probe、Playwright、远程浏览器截图、用户路径 E2E 或等价重型业务探针。业务/用户入口验证只能作为发布后的独立 post-deploy validation 证据，不得阻塞 CI/CD 一键交付。
  • 任一 CI/CD 阶段或总耗时超过 2 分钟时，不要继续死等或把超长等待视为正常；先输出阶段耗时分解，并优先从 env reuse、git mirror、BuildKit/cache、GitOps/Argo watch 和 runtime readiness 探测方向优化后再继续交付。
  • node-scoped trigger-current --wait 必须把 source sync、pre/post flush、PipelineRun、GitOps/Argo、runtime readiness 和 /health closeout 放进同一 120s 端到端预算；超预算时由 CLI 输出阶段分解、Argo target revision、runtime/public 状态和 TaskRun/Pod drill-down，不继续死等，也不要求操作者手动串联多个状态/flush 命令才能完成一次交付。
  • 触发或验收 rollout 时必须绑定 lane、source commit、PipelineRun/GitOps revision、runtime ready 和 /health 端点验证结果；web-probe/Playwright 结果只能作为单独的 post-deploy 证据。
  • Secret 只通过 YAML sourceRef/targetKey 和受控 CLI 下发；输出只披露 presence/fingerprint。
  • 长命令用异步 job 或短轮询；不要长时间挂住 trans/ssh。

何时读取 reference

Reference in New Issue View Git Blame Copy Permalink