Sync the self-hosting stack

2026-08-30 09:58:08 +02:00
parent cd7d807a4f
commit 9b5020dea0
12 changed files with 392 additions and 2 deletions
@@ -10,8 +10,17 @@
 #   observable status, a bounded number of retries, and a failure that stops the rollout instead of
 #   letting it proceed against a schema that was never applied.
 #
-# With Helm this becomes a `pre-install,pre-upgrade` hook; with Argo, a sync-wave. Applied by hand,
-# the ordering is yours to keep — see the README.
+# UNDER ARGO CD IT IS A SYNC HOOK, and that is not decoration — it is what makes this directory
+# reconcilable at all. A Job's `spec.template` is immutable, so an ordinary Job whose image digest
+# changed is a patch the API server REFUSES: the sync fails on "field is immutable" and the release
+# stops, every time, from the second release onwards. `BeforeHookCreation` deletes the previous Job
+# before creating this one, which is the supported way of saying "run it again, with new contents".
+#
+# It costs one thing worth knowing: the previous run's Job object, and its logs, are gone by the
+# time the next one starts. Ship the logs elsewhere if you need them after the fact.
+#
+# With Helm this is a `pre-install,pre-upgrade` hook instead. Applied by hand, the ordering is yours
+# to keep — see the README.
 #
 # It is safe to run twice: every pass is idempotent and the whole phase is wrapped in a Postgres
 # advisory lock, so a second copy waits rather than racing.
@@ -20,6 +29,17 @@ kind: Job
 metadata:
  name: jarvis-migrate
  namespace: jarvis
+  annotations:
+    # The SYNC phase, not PreSync. A PreSync hook runs in a phase of its own, before any ordinary
+    # resource is applied — which on a first sync means before the namespace, the ConfigMap and the
+    # Secret this Job reads exist. In the Sync phase it is ordered by the same waves as everything
+    # else, so "after the config, before the api" is one number rather than a second mechanism.
+    argocd.argoproj.io/hook: Sync
+    argocd.argoproj.io/hook-delete-policy: BeforeHookCreation
+    # After the config and the minting (waves -2 and -1), before any api pod (wave 1). Argo does not
+    # begin the next wave until this Job reports complete, which is the ordering the README's
+    # `kubectl wait` keeps by hand.
+    argocd.argoproj.io/sync-wave: "0"
 spec:
  # One writer. The lock makes a second one wait rather than corrupt, but there is no reason to
  # have one waiting.