fix(server): set S3 boot config on the migrate Job for managed deploys

What changed

In infra/helm/tuist/templates/server-migration-job.yaml, the TUIST_S3_* env block was wrapped in {{- if not .Values.server.managedSecrets }}. This moves the boot-config S3 vars (TUIST_S3_BUCKET_NAME, TUIST_S3_ENDPOINT, TUIST_S3_REGION, TUIST_S3_VIRTUAL_HOST, TUIST_S3_BUCKET_AS_HOST) out of that guard so they are set unconditionally, mirroring server-deployment.yaml, which already sets them unconditionally. The S3 credential refs (*_ACCESS_KEY_ID / *_SECRET_ACCESS_KEY) stay gated as before.

Why — root cause

The release’s config/runtime.exs configures ex_aws for every non-test environment at boot:

%{host: ...} = secrets |> Tuist.Environment.s3_endpoint() |> URI.parse()   # runtime.exs:425

Environment.s3_endpoint/1 resolves TUIST_S3_ENDPOINT first, then falls back to get([:s3, :endpoint]) (the encrypted blob).

For managed deployments (managedSecrets: true) the migrate Job’s TUIST_S3_ENDPOINT was never set — it was gated behind not managedSecrets — so it relied on the blob’s s3.endpoint. #11460 removed the encrypted blob (decrypt_secrets/0 now returns %{}), so s3_endpoint() became nil, and URI.parse(nil) raises a FunctionClauseError during config-provider boot. The pre-upgrade migration hook crashed on every attempt before running any migration, and helm upgrade --wait hung until the canary deploy failed — wedging the cascade.

The server Deployment was unaffected because it already sets TUIST_S3_ENDPOINT unconditionally; only the migrate Job still leaned on the blob.

Why this solution

The migrate Job doesn’t use S3, but runtime.exs parses the endpoint at boot regardless, so the endpoint must be a valid string. Setting the same values the server Deployment uses (via the existing tuist.objectStorage* helpers) is the minimal change that restores parity. The credential refs are left gated because migrations never make S3 calls.

Impact

• Managed deploys: the migrate hook boots and runs migrations again; the production deployment cascade is unblocked.
• Self-hosted (managedSecrets: false): unchanged behavior — still gets the same S3 env (verified below).
• No application code change; chart-only.

Validation

helm template of the migrate Job:

• Managed (values-managed-common + values-managed-production): TUIST_S3_ENDPOINT: "https://t3.storage.dev" present exactly once (previously absent → the crash).
• Self-hosted (defaults): TUIST_S3_ENDPOINT: "http://tuist-tuist-object-storage:9000" present exactly once — no regression.

Discovered live: the 36ef22f0a11 canary deploy crash-looped the migrate hook with ** (FunctionClauseError) URI.parse(nil) ... runtime.exs:425; this is the fix.

🤖 Generated with Claude Code

No GitHub comments yet.