coulomb/activity-core
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat: guard prod status since-arg; plan Glas contract adoption
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
Build and Publish Container Image / build-and-push (push) Successful in 5s
Details

Browse source 
scripts/prod_automation_status.sh took a positional since value, so the
Makefile's own `SINCE=sunday` form passed the literal string into timestamptz:
all five sections errored while the run still looked like it produced a report.
Now `SINCE=` is accepted and the value is parsed and normalised to UTC up
front, failing fast with usage and exit 2 instead of five parse errors.

ACTIVITY-WP-0032 plans adoption of the glas-harness contract 1.0 reported in
GLAS-WP-0004. WP-0026 is finished, so this gets its own plan. The motivation is
concrete: ops_run.approach_hint binds at claim time, which produced a failed
run on 2026-08-17 ("no approach matched labels/definition") after it had
already consumed a claim and a lease.

T01 is deliberately blocking: our claim path is pull-based and the Glas
contract is a call, so the invocation shape is an architectural decision, not a
port. Two questions are outstanding with glas-harness.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 09:05:04 +02:00
parent 459a272974
commit 17f2caee01
2 changed files with 210 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

38
scripts/prod_automation_status.sh
View file

@ -9,6 +9,22 @@ SINCE_ARG="${1:-sunday}"
SSH_HOST="${PROD_AUTOMATION_SSH_HOST:-railiance01}"
NS="${PROD_AUTOMATION_NS:-activity-core}"
# The Makefile target is `make prod-automation-status SINCE=sunday`, so operators
# reasonably type the same `SINCE=` form when calling the script directly. Accept
# it rather than passing the literal into timestamptz, where every section fails
# with a separate parse error while the run still looks like it produced a report.
if [[ "$SINCE_ARG" == SINCE=* ]]; then
SINCE_ARG="${SINCE_ARG#SINCE=}"
fi
usage() {
cat >&2 <<'USAGE'
Usage: ./scripts/prod_automation_status.sh [since]
since: "sunday" (default) | an ISO-8601 timestamp, e.g. 2026-08-17T00:00:00Z
Read-only. Requires SSH to the production host.
USAGE
}
if [[ "$SINCE_ARG" == "sunday" ]]; then
# Floor of most recent Sunday 00:00 Europe/Berlin in UTC (portable enough for ops).
SINCE_UTC="$(python3 - <<'PY'
@ -22,7 +38,27 @@ print(sunday.astimezone(timezone.utc).strftime("%Y-%m-%d %H:%M:%S%z"))
PY
)"
else
SINCE_UTC="$SINCE_ARG"
# Validate before the value reaches five separate SQL/JSON consumers: an
# unparseable `since` must fail fast and loudly, not produce a report whose
# every section is an error the reader has to notice.
if ! SINCE_UTC="$(python3 - "$SINCE_ARG" <<'PYVALIDATE'
import sys
from datetime import datetime, timezone
raw = sys.argv[1].strip()
try:
parsed = datetime.fromisoformat(raw.replace("Z", "+00:00"))
except ValueError:
sys.exit(1)
if parsed.tzinfo is None:
parsed = parsed.replace(tzinfo=timezone.utc)
print(parsed.astimezone(timezone.utc).strftime("%Y-%m-%d %H:%M:%S%z"))
PYVALIDATE
)"; then
echo "error: could not parse since value: ${SINCE_ARG}" >&2
usage
exit 2
fi
fi
echo "=== prod automation status (railiance01) since ${SINCE_UTC} ==="