hush/scripts
jx12n bc33747568
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
release: poll the build Job instead of watching it
Measured on the previous commit's release: the Kaniko Job reached Complete in
156s and pushed registry.threesix.ai/hush/api:d7cd57f3, and
`kubectl wait --for=condition=complete` sat on its watch until the 900s
timeout, then reported "build FAILED" and exited before the rollout. The
image existed; the deploy did not happen; the message said the opposite of
what had happened.

One long watch against a cluster across a WAN link is the wrong instrument. A
fresh short GET every 5s costs one poll when a connection drops, distinguishes
`.status.failed` from "not finished yet", and reports the deadline as "may
still be running" with the two commands to check — never as a failure.

Both branches exercised against the cluster with the loop as committed: a Job
that exits 1 is reported as FAILED with its last lines, and the already
complete d7cd57f3 Job breaks the loop immediately.
2026-09-05 14:21:19 -06:00
..
alerts-check.sh docs, ops scripts, and the MCP install 2026-09-03 00:18:53 -06:00
format-logs.py docs, ops scripts, and the MCP install 2026-09-03 00:18:53 -06:00
install-mcp.sh docs, ops scripts, and the MCP install 2026-09-03 00:18:53 -06:00
logs.sh docs, ops scripts, and the MCP install 2026-09-03 00:18:53 -06:00
release.sh release: poll the build Job instead of watching it 2026-09-05 14:21:19 -06:00
smoke.sh serve the MCP install instructions at /mcp 2026-09-05 14:03:34 -06:00