activity-core/docs/gitops-release.md
tegwick c12a8fbcfb
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 7s
Build and Publish Container Image / build-and-push (push) Successful in 2m18s
Prepare scoped GitOps adoption and tested immutable image releases
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e241-8285-7a63-8c0c-51c9cb824dc3
2026-09-27 13:50:16 +02:00

4 KiB

Activity-core GitOps release lane

ACTIVITY-WP-0041 owns this lane; RPF-WP-0048 owns platform adoption. The founder requested implementation on 2026-09-27. Adoption is authorized; the existing 24-hour healthy observation period and release-identity proof remain mandatory.

Managed set and ownership

k8s/gitops/kustomization.yaml renders exactly nine resources: the API, worker and event-router Deployments; API and worker-metrics Services; runtime config, external definitions, report schemas and service-inventory ConfigMaps. scripts/render_gitops.py --check verifies the generated projection against k8s/railiance/20-runtime.yaml. Change that source and regenerate; after adoption, never apply the mixed legacy directory directly. Migration/sync Jobs are deliberately excluded. Sync definitions through the existing authenticated admin endpoint after ConfigMap projection refresh; this is an explicit release verification step.

The baseline includes live backup wrapper mounts and the API's Temporal UI setting. Dependencies stay with their existing owners: ESO/OpenBao secrets, verified backup ConfigMap, storage, host-path contents, Temporal/NATS/databases, llm-connect, edge relay, ingress/SSO and monitoring. ArgoCD must not prune or adopt them implicitly. Namespace classification remains production-tier (platform target, no authoritative rApp binding); MASON-WP-0006 is the mapping owner. Adoption does not invent a binding or lower readiness requirements.

Build and publication

The image workflow retrieves the full commit archive, builds the isolated test stage, and publishes only git-<full-sha> plus its registry digest. Python's base image digest, uv version and dependency lock are pinned. Deployments consume forgejo.coulomb.social/coulomb/activity-core@sha256:…, independently for each component. A commit tag is a lookup convenience, not an immutability guarantee. Existing images are retained during metadata-only adoption; do not replace a running component with newer code merely to complete adoption.

The pipeline uses its existing runner-held registry credentials. No credentials are copied into Git or into the coding-agent session. Successful publication and anonymous/cluster pull must be evidenced before the first digest promotion.

Bounded routine authority — implementation boundary

Proposed executable scope ACTIVITY-WP-0041-image-only-v1 is intentionally narrow: only the three Deployment image fields and transition from Never to IfNotPresent may change. No resource inventory, commands, mounts, environment, access, schema, replicas, resources, migrations, definition behavior or budget changes are admitted. Those changes require their owner review under the existing governance policy.

scripts/check_gitops_promotion.py refuses a non-digest image, widened diff, missing independent review/checks, unadmitted identity, stale health evidence, missing rollback revision, or less than 24 healthy hours. It is a validator, not an authority issuer: evidence fields are not signatures. The release executor must authenticate the CI/reviewer/health receipts and bind the exact candidate revision before invoking it. A producer-supplied JSON file cannot grant access.

No unattended merge/deployment identity has been admitted by this change. Do not mark this policy active or turn on automatic sync based only on these fixtures. After identity proof and the observation period, enable only the activity-core child's bounded promotion path; root-wide automation and destructive pruning stay off. The existing root remains manually reconciled for unrelated applications.

A release must name the prior pinned revision before promotion, sync through ArgoCD with pruning disabled, verify health and report-sink/schedule invariants, and revert its source revision through ArgoCD on failure. Prove both successful promotion and failed-health rollback before claiming unattended operation. The 24-hour observation begins with the recorded successful adoption; a stateful failure or unintended spec change invalidates that observation.