Public: anyone can read this; the crew can change it.
docs/CLUSTER.md says exactly what an operator applies to turn the check lane on, matching what the code reads #2318
Check · Review · Land · Live done — Landed and live in production.
I added `docs/CLUSTER.md` and `test/cluster-doc.test.ts`. The new test file passes, and `charts/` is untouched. I didn't run the rest of `bun test` or the type check, since the forge runs the full check on push.
shipped production is serving it deploy 6365650
I added docs/CLUSTER.md and test/cluster-doc.test.ts. The new test file passes, and charts/ is untouched. I didn't run the rest of bun test or the type check, since the forge runs the full check on push.
The doc covers:
- Role: a table and a YAML snippet for the verbs
src/cluster/jobs.tsuses, each with its reason. Those arecreate,getanddeleteonbatchjobs,listonpods, andgetonpods/log. Nowatchorupdateis used, so none are granted. - Environment: all five
FORGE_CHECKS_*variables fromsrc/checks/placement.ts, each with an example value. - NetworkPolicy label:
forge-check: "true"(JOB_LABELSinsrc/checks/job_step.ts), with apodSelectorsnippet. - Confirming the lane is on: four steps. The run says "ran as a cluster job on <node>",
kubectl get jobs,pods -l forge-check=trueshows the Job while it runs, and silence means the forge fell back toprocess.
The test fails if the doc drifts: it reads the FORGE_CHECKS_* names out of placement.ts and checks each one appears in the doc. It also checks the JOB_LABELS pair is written as key: "value", and that the doc grants the verb matching each HTTP method jobs.ts calls. The list and pods/log entries are only checked as fixed strings, because the code reaches those through other helpers.
Not done: the Role isn't shipped as a chart template, because the chart belongs to the owner. I also didn't change docs/APPS.md, which already describes placement in prose.
Docs-only; I checked the page against the code and it matches. jobs.ts calls POST/GET/DELETE on batch jobs, GET on pods filtered by job-name, and GET on pods/log. placement.ts reads exactly the five FORGE_CHECKS_* variables. JOB_LABELS is forge-check: "true". The "ran as a cluster job on <node>" wording is the string in placement.ts. The Role is least-privilege, and the chart is untouched. There is no UI change, so nothing to break on a phone or without a mouse. Two things I would do next: (1) tighten the drift test: the list and pods/log checks are fixed strings, so a verb dropped from the table but still present in the YAML would pass. Assert the YAML block and the table separately, or parse the rules. (2) Link this page from docs/APPS.md, where placement is described in prose, so an operator finds it.
I added
docs/CLUSTER.mdandtest/cluster-doc.test.ts. The new test file passes, andcharts/is untouched. I didn't run the rest ofbun testor the type check, since the forge runs the full check on push.The doc covers:
src/cluster/jobs.tsuses, each with its reason. Those arecreate,getanddeleteonbatchjobs,listonpods, andgetonpods/log. Nowatchorupdateis used, so none are granted.FORGE_CHECKS_*variables fromsrc/checks/placement.ts, each with an example value.forge-check: "true"(JOB_LABELSinsrc/checks/job_step.ts), with apodSelectorsnippet.kubectl get jobs,pods -l forge-check=trueshows the Job while it runs, and silence means the forge fell back toprocess.The test fails if the doc drifts: it reads the
FORGE_CHECKS_*names out ofplacement.tsand checks each one appears in the doc. It also checks theJOB_LABELSpair is written askey: "value", and that the doc grants the verb matching each HTTP methodjobs.tscalls. Thelistandpods/logentries are only checked as fixed strings, because the code reaches those through other helpers.Not done: the Role isn't shipped as a chart template, because the chart belongs to the owner. I also didn't change
docs/APPS.md, which already describes placement in prose.Closes #2287