Files
certctl/deploy
shankar0123 151107c969 fix(test-compose): set CERTCTL_AGENT_BOOTSTRAP_TOKEN placeholder (deploy-vendor-e2e job)
deploy-vendor-e2e was hidden behind the go-build-and-test failure; once
that cleared (b1ca046), the vendor-e2e job actually booted certctl-test-
server for the first time in a while and hit the Sprint 5 ACQ RED-003
fallout:

  Failed to load configuration: phase-2 SEC-H1 fail-closed guard:
  CERTCTL_AGENT_BOOTSTRAP_TOKEN is empty and
  CERTCTL_AGENT_BOOTSTRAP_TOKEN_DENY_EMPTY=true — refuse to start.

The Sprint 5 RED-003 closure flipped DENY_EMPTY's default from false→true
in production code, but the test compose stack never set a token. The
fail-closed guard (internal/config/config.go:1054) refuses to start
unless one of:
  - CERTCTL_AGENT_BOOTSTRAP_TOKEN is non-empty, OR
  - CERTCTL_DEMO_MODE_ACK=true (demo-mode override), OR
  - CERTCTL_AGENT_BOOTSTRAP_TOKEN_DENY_EMPTY=false (warn-mode escape
    hatch for v2.1.x→v2.2.x upgrade window)

This is the e2e TEST stack with production-like auth posture
(CERTCTL_AUTH_TYPE=api-key), not a demo stack. The right fix is the
first option — set a deterministic placeholder token. Picking the
warn-mode escape hatch would silently test the wrong posture; picking
DEMO_MODE_ACK would also flip CERTCTL_AUTH_TYPE expectations.

Also fixed deploy/ENVIRONMENTS.md: the entry still said
'default flip to true scheduled for v2.2.0', which became stale on
2026-05-16 when Sprint 5 ACQ RED-003 actually flipped it. Updated the
default column from `false` to `true` and rewrote the description
to reflect the current posture + the v2.1.x→v2.2.x warn-mode escape
hatch.

Verified locally: all 53 locally-runnable ci-guards still green
(4 skipped: H-001-bare-from + H-002-bare-compose-image + digest-validity
+ no-precompiled-binary, all need docker-registry network).

CI re-run on this commit should clear deploy-vendor-e2e's
certctl-test-server dependency-failed-to-start step.
2026-05-16 23:15:22 +00:00
..