You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to #85 and #88. **Net effect: the Ready-gated idempotency
corpus stays skipped, but for accurate reasons, plus a diagnostics
dump.** (This branch briefly un-skipped the corpus to find out what was
actually blocking Ready — that investigation is summarized below.)
## What the investigation found
#68 (the `init-uv` contract) is **fixed**: #85 ships the lockfiles at
`/opt/venv-template/`, #88 ships the `uv` binary, and `v2026.5.29.2` was
republished + verified. `init-uv` now succeeds and the pod reaches its
main `hermes` container.
But un-skipping showed the instance still can't become Ready in CI —
three deeper, separate blockers (surfaced by the new diagnostics dump):
1. **No LLM provider** — the published hermes-agent exits immediately
without a provider + credentials (`Failed to initialize agent: No LLM
provider configured`). CI fixtures carry none → container exits 0 →
CrashLoopBackOff.
2. **Wrong serve command / port model** — the long-lived agent is
`hermes gateway run` (a chat-platform daemon that binds **no** `:8443`
server), not the one-shot `hermes-agent run` the image entrypoint
invokes. The operator's `TCPSocket :8443` readiness probe can't pass
as-is.
3. **Missing image deps** — `websockets`, `hermes_cli.dashboard_auth`.
Reaching Ready in CI needs design-level decisions (inject LLM creds,
rework the entrypoint/readiness/port model, fix image deps) — out of
scope for the #68 image fix.
## This PR
- Keeps the corpus skipped, but replaces the stale `#68` skip reason
with `idempotencyReadyBlockedSkip` describing the real blockers (and
noting #68 is resolved). Tracked under #64.
- Adds `dumpInstanceDiagnostics` to `waitForInstanceReady` (instance
YAML, pods/sts, describe, events, init-container logs) so the next Ready
attempt is debuggable from the CI log instead of a bare timeout.
Conformance stays green (skips). Un-skip once an instance can actually
reach Ready in CI.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: test/conformance/idempotency_test.go
+37-27Lines changed: 37 additions & 27 deletions
Original file line number
Diff line number
Diff line change
@@ -14,18 +14,29 @@ import (
14
14
// more times. After each requeue we assert the resourceFingerprint is unchanged
15
15
// (generation + resourceVersion must not move). This catches lesson #437
16
16
// regressions: a reconciler that always re-writes owned objects will fail here.
17
-
// idempotencyImageContractSkip documents why the Ready-gated idempotency corpus
18
-
// is currently skipped. Once the conformance suite actually runs (#64), every
19
-
// HermesInstance fails to reach Ready: the operator's `init-uv` init container
20
-
// (internal/resources/runtime_init.go) copies pyproject.toml/uv.lock from
21
-
// /opt/venv-template/, but the published ghcr.io/paperclipinc/hermes-agent image
22
-
// builds its venv at /opt/venv and ships nothing at /opt/venv-template/. The init
23
-
// container exits 1, the pod never starts the hermes container, and the
24
-
// StatefulSet never reaches readyReplicas==replicas. That is an operator/agent
25
-
// image contract bug unrelated to reconciler idempotency, tracked in #68. These
26
-
// entries are skipped (visibly, with this reason) rather than left to hang until
27
-
// timeout and fail. Remove the skips once #68 is fixed.
28
-
constidempotencyImageContractSkip="blocked by #68: operator init-uv copies from /opt/venv-template which is absent in the published hermes-agent image, so no HermesInstance reaches Ready; unskip once #68 is fixed"
17
+
// The Ready-gated corpus stays skipped, but the reason has moved on from #68.
18
+
//
19
+
// #68 (the init-uv contract: lockfiles missing at /opt/venv-template/) is fixed
20
+
// — #85 ships the lockfiles, #88 ships the uv binary, and v2026.5.29.2 was
21
+
// republished. With that, init-uv now succeeds (verified) and the pod reaches
22
+
// its main `hermes` container. But the instance still cannot become Ready in CI:
23
+
//
24
+
// 1. The published hermes-agent exits immediately unless an LLM provider +
25
+
// credentials are configured ("Failed to initialize agent: No LLM provider
26
+
// configured"). The CI fixtures carry none, so the container exits 0 and
27
+
// CrashLoopBackOffs.
28
+
// 2. The agent's long-lived form is `hermes gateway run` (a chat-platform
29
+
// daemon), not the one-shot `hermes-agent run` the image entrypoint invokes
30
+
// — and it binds no :8443 server, so the operator's TCPSocket :8443
31
+
// readiness probe cannot pass as-is.
32
+
// 3. The published image is missing modules (websockets, hermes_cli.dashboard_auth).
33
+
//
34
+
// Reaching Ready in CI therefore needs design-level decisions (inject LLM
35
+
// credentials, rework the entrypoint/readiness/port model, fix image deps), not
36
+
// just the #68 image fix. Tracked under #64. waitForInstanceReady now dumps pod
37
+
// diagnostics on timeout so the blocker is visible in the CI log. Unskip these
38
+
// once an instance can actually reach Ready in CI.
39
+
constidempotencyReadyBlockedSkip="cannot reach Ready in CI: hermes-agent needs an LLM provider+credentials to start and the operator's :8443 gateway-readiness model does not match the chat-gateway agent (see #64); the #68 init-uv contract itself is fixed (#85, #88)"
29
40
30
41
varidempotencyCorpus= []struct {
31
42
labelstring
@@ -36,27 +47,26 @@ var idempotencyCorpus = []struct {
0 commit comments