The fixture check waited on the Job's .status.succeeded/.status.failed. The
kubelet records a container's exit code the instant it stops, but the Job
controller reconciles those fields on its own schedule: observed at 2m24s,
4m27s and 34m on this cluster for identical work. During that window the pod
had already exited 1 and the build sat printing 'Will try again after 13 sec',
looking hung long after the test had finished, which is unusable in a demo.
Polling the pod's terminated exitCode removes the controller from the path
entirely. The Job is still used, so the evidence shape is unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Indexing succeeded but discovered no branches without an explicit
gitBranchDiscovery trait, so hermes-repair/* never got a validation build.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds demo driver script and branch-level test gate so a Hermes-proposed
pull request carries a green build before human merge.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Pipeline ensures the fixture ConfigMap and seeds unhealthy via patch-file
- Test-runner mounts the ConfigMap read-only; no storage attach involved
- New hermes-demo-repair SA + Role scoped to patching only the fixture CM
- Removes the fixture PVC (Flux prunes it)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- New hermes-triage-demo namespace with fixture PVC and RBAC scoped to
Jenkins agent Job creation only
- JCasC pipelineJob hermes-triage-demo: SEED_FAILURE-parameterized fixture
check running as a Kubernetes Job in the demo namespace, emitting the
incident ID to pod stdout (Fluent Bit -> OpenSearch kube-*) and JUnit to
Jenkins
- Hermes init container can seed API_SERVER_KEY in the persistent .env
from an optional hermes-api-server-key Secret (no-op until it exists)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
