docs: close out runner retention repair
Pipelines as Code CI / hwlab-web-probe-sentinel-nc01- Success
Pipelines as Code CI / platform-infra-gitea-nc01- Success
Pipelines as Code CI / unidesk-host- Success

This commit is contained in:
Codex
2026-07-12 19:05:26 +02:00
parent 9d1e1c381a
commit 3ea06cabdb
4 changed files with 27 additions and 12 deletions
@@ -12,7 +12,7 @@ bun scripts/cli.ts agentrun control-plane apply --node D601 --lane v02 [--dry-ru
bun scripts/cli.ts agentrun control-plane secret-sync --node D601 --lane v02 [--dry-run|--confirm]
bun scripts/cli.ts agentrun control-plane restart --node D601 --lane v02 [--dry-run|--confirm]
bun scripts/cli.ts agentrun control-plane trigger-current --node D601 --lane v02 [--dry-run|--confirm]
bun scripts/cli.ts agentrun control-plane cleanup-runners --node D601 --lane v02 [--dry-run|--confirm]
bun scripts/cli.ts agentrun control-plane cleanup-runners --node D601 --lane v02 --dry-run
bun scripts/cli.ts agentrun describe runnerjob/<runnerJobId> --run <runId> --node D601 --lane v02 -o json
bun scripts/cli.ts agentrun control-plane status --node D601 --lane v02 [--pipeline-run <name>|--source-commit <sha>] [--full|--raw]
bun scripts/cli.ts platform-infra gitea mirror status --target JD01 [--full|--raw]
@@ -29,11 +29,11 @@ bun scripts/cli.ts platform-infra pipelines-as-code status --target JD01 [--full
- 默认有界显示 observation、capacity、最近活跃、heartbeat、业务进展、Pod waiting reason 和 `stale-pending`
- capacity 摘要必须显示 `<runnerJobCount>/<maxRunners>``status``availableSlots`、typed blocker 和 `degradedReason`
- `runnerJobCount === maxRunners` 时必须返回 at-capacity degraded,不能在下一 runner 已依赖 manager retention 时继续报告健康;
- `--confirm` 在 UniDesk 侧固定 fail-closed,不按旧 Job 名称删除
- 真正删除由 AgentRun manager 的 DB fence 和 Kubernetes CAS 原子入口负责:
- 分类与 pre-create retention 跟踪 [AgentRun #280](https://github.com/pikasTech/agentrun/issues/280)
- 原子实现跟踪 [PR #281](https://github.com/pikasTech/agentrun/pull/281)
- 无 incoming create 时的批量陈旧对象终态化和回收由同一 manager authority 的 [AgentRun #282](https://github.com/pikasTech/agentrun/issues/282) 跟踪
- UniDesk 不提供 runner 强杀入口,也不按名称删除 Job/Pod
- AgentRun manager 的既有周期 reconciler 与 pre-create retention 负责自动分批回收;
- 终态事实必须优先于历史 claim、heartbeat 和 Pod 活性观察
- `runner-dispatch-retry` 不属于业务进展,不能永久保护 pending runner
- 空闲运行面的验收值是 `runnerJobCount=0``protectedActiveRunnerCount=0`
- `describe runnerjob/<runnerJobId>`:
- 先通过 manager 精确读取 runner job identity
- 再按精确 Job name、`job-name` Pod label 和 Pod name Warning Event 查询运行面;