feat: add opt-in gitops mode for deterministic rendering (plane-enterprise + plane-ce)#244
feat: add opt-in gitops mode for deterministic rendering (plane-enterprise + plane-ce)#244sfasching wants to merge 1 commit into
Conversation
…prise + plane-ce) Adds a gitops.enabled flag (default false) to both charts. When false they render byte-for-byte as today. When true, the per-render timestamp pod annotation is omitted and migration Job names are keyed to planeVersion (instead of a wall-clock timestamp in plane-enterprise / .Release.Revision in plane-ce), so Argo CD/Flux get a deterministic render: no perpetual drift and no immutable-Job patch errors. Relates to makeplane#158, makeplane#206, makeplane#207. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (31)
WalkthroughAdds a ChangesGitOps Deterministic Rendering
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Trivy (0.69.3)Trivy execution failed: 2026-06-15T03:17:18Z FATAL Fatal error run error: fs scan error: scan error: scan failed: failed analysis: post analysis error: post analysis error: cloudformation scan error: fs filter error: fs filter error: walk error range error: stat gitleaks-report-29.json: no such file or directory: range error: stat gitleaks-report-29.json: no such file or directory Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Adds an opt-in
gitops.enabledflag (defaultfalse) to bothplane-enterpriseandplane-ce, so the charts render deterministically for declarative GitOps tools (Argo CD, Flux) — without changing anything for existinghelm install/helm upgradeusers.gitops.enabled: false(default): renders byte-for-byte identical to today.gitops.enabled: true: omits the per-rendertimestamp: {{ now | quote }}pod annotation, and keys migration Job names to.Values.planeVersion(instead of a wall-clock timestamp in plane-enterprise /.Release.Revisionin plane-ce).Why
Several workload templates inject
timestamp: {{ now | quote }}intospec.template.metadata.annotations, and the migration Jobs derivemetadata.namefrom a per-render value. Under a GitOps reconciler this is fatal:Synced; rolls every pod on every reconcile — each Deployment's pod template differs on each render.field is immutable— Argo CD tries to patch the existing Job, butJob.spec.templateis immutable.Reported in #158 (closed "intentional; couldn't reproduce the migrator breakage") and #206 (the exact immutable-Job failure), then worked around in #207 by making the plane-enterprise Job name timestamp-unique — which avoids the immutable error but runs the migration on every sync and orphans a Job each time. This fixes the root cause while preserving the intended default.
Design — non-breaking, opt-in
nowforces a rollout on everyhelm upgrade— reasonable for imperative users, so it stays the default; only opted-in GitOps users change behavior:gitops.enabled: false(default)gitops.enabled: truetimestampannotationnow/.Release.Revision)planeVersionVersion-keyed Job names are deterministic per release, re-run cleanly on a version bump (new name → new Job; Argo CD prunes the old one), and never hit the immutable-Job patch. The charts already ship
reloader.stakater.com/autoon some workloads — the deterministic, config-driven rollout mechanism — so GitOps users don't lose config-change rollouts by dropping thenowannotation.Proof it doesn't change the default
helm templatewith default values is identical to the current chart (modulo thenowvalues that already differ between any two renders), for both charts:With
gitops.enabled=true, repeated renders are identical and contain nonow:Scope
charts/plane-enterpriseandcharts/plane-ce— thetimestampannotation in their workload templates, version-keyed migration Job names, and thegitops.enabledvalues flag. No default-behavior change in either chart.Relates to #158, #206, #207.
Summary by CodeRabbit
New Features
Configuration
gitopsconfiguration block added (default: disabled). When enabled, timestamp annotations are excluded from deployments and job names are derived from version instead of timestamps for consistent, repeatable deployments.