feat-bp-kyverno-policies-split-chart
2 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
e3mrah
|
cadc7b5cea
|
fix(sandbox-ci): mcp-server Dockerfile repo-root context + pty/mcp auto-bump wiring (chart was half-deployable) (#1667)
Sandbox chart was un-deployable end-to-end because three CI-side gaps compounded after PR #1658 wired the mcp-server module to depend on core/controllers + core/services/shared via `replace` directives: 1. **mcp-server Dockerfile built against a too-narrow context**. The workflow passed `context: products/sandbox/mcp-server` and the Dockerfile assumed `COPY . .` could see everything it needed, but the `replace ../../../core/controllers` line in the module's go.mod only resolves when the build can actually reach those paths. Result: every push after #1658 failed at `go build` with `module not found`. Fix mirrors core/controllers/sandbox/Dockerfile (Slice-CC1 layout): COPY the replace targets' module roots + sources, then build with WORKDIR set to the dependent module. Static binary still produced into a distroless/static-debian12:nonroot final stage. 2. **mcp-server workflow had no chart auto-bump step**. Even after a green build, `runtime.mcpImage` in platform/sandbox/chart/values.yaml stayed empty so the chart's `required` guard (deployment.yaml line 72) refused to render. Added the same yq-bump + bot-commit pattern build-sandbox-controller.yaml already uses, targeting `.runtime.mcpImage` and writing a fully-qualified `<repo>:<sha>` string (consumer reads it as one image reference, not a {repository,tag} pair). Also widened paths-filter to include core/controllers/** + core/services/shared/** so changes to the replace targets re-trigger the build. 3. **pty-server workflow had no auto-bump either**. Same surgery: yq-bump `.runtime.ptyServerImage` + commit-and-push. Context stays narrow (pty-server has no cross-tree `replace` directives). 4. **Stop-gap pin values for runtime.{ptyServerImage,mcpImage}** so the next chart roll out doesn't fail-fast before the rebuilt workflows land their first bumps: - ptyServerImage → |
||
|
e3mrah
|
1b0e86cb1a
|
ci(sandbox): build workflows for controller + pty-server + mcp-server (so chart can actually deploy) (#1632)
PR #1622 shipped the sandbox-controller binary + chart, and PR #1618 shipped pty-server + mcp-server scaffolds, but neither came with CI build workflows — meaning the chart's image.repository points at a GHCR package that no workflow ever publishes (ImagePullBackOff on every install). Per docs/INVIOLABLE-PRINCIPLES.md #4a every runtime image MUST be produced by a GitHub Actions workflow from a committed git SHA; this PR closes that gap. Three new workflows, all event-driven (push paths-filter + PR + workflow_dispatch, no cron): - build-sandbox-controller.yaml — mirrors build-application-controller (shared core/controllers go.mod, go vet + race tests, Buildx push, cosign keyless sign, SBOM attest, auto-bump platform/sandbox/chart/ values.yaml image.tag back to main so the next install picks up the SHA-pinned image without operator action). - build-sandbox-pty-server.yaml — separate go module under products/sandbox/pty-server (own go.mod/go.sum), Dockerfile uses COPY . . so build context is the server directory. Same Buildx + cosign + SBOM flow as the controller. No values.yaml bump yet: Wave-2 wiring of the StatefulSet template will land in a follow-up. - build-sandbox-mcp-server.yaml — stdlib-only stdio MCP sidecar (no go.sum yet), same shape as pty-server. Per `feedback_no_mvp_no_workarounds.md` rule 1 (target-state, never "manual follow-up bump") the controller workflow auto-bumps the chart values.yaml so a Sovereign overlay flipping `enabled: true` Just Works. Per the user's hard rule for this PR, no Chart.yaml bump and no blueprint-release dispatch — the Sandbox chart's publication cadence is gated by Wave-2 readiness, not per-image builds. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |