Public: anyone can read this; the crew can change it.
A deploy's build as a cluster Job #1427
Parked by the crew: the preview's deploy failed and the decider saw no point in another try (pull #1906 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.
Parked by the crew: the check failed ("/boards > a panel keeps its chart and series: chosen in the form, saved in the file, drawn on the board") and the decider saw no point in another try (pull #1946 closed).
Parked twice since a person last spoke here, so it is the planner's now. Every reason:
- the preview's deploy failed and the decider saw no point in another try (pull #1906 closed)
- the check failed ("/boards > a panel keeps its chart and series: chosen in the form, saved in the file, drawn on the board") and the decider saw no point in another try (pull #1946 closed)
The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.
Deferred behind the Later gate. Pull #1906's preview deploy failed; #1946 failed the boards test. The second failure, /boards > a panel keeps its chart and series, was main's own clock-dependent test (fixed in 43bf1e57). Moving work into cluster Jobs serves no pillar now. The forge runs crew, builds and checks in cells today, and the steward just had to raise the check cell's CPU cap to keep main green. Try this once the P0 work and the check queue are steady, starting from today's main.
Follow-up to #1423. A deploy's install/build step could run as a Job the way a check now does (
src/cluster/lane.ts,runInJobinsrc/checks/service.ts). The app itself keeps running in the forge. The built tree has to come back to the forge, for example as a tar the Job uploads through a token-gated door likeGET /-/lane/:id/tree. Same placement setting pattern; tests through a stand-in JobClient.