fix(server): wire the license key into the processor deployments

What changed

Adds {{- include "tuist.licenseEnv" . }} to processor-deployment.yaml and xcresult-processor-deployment.yaml, so both get TUIST_LICENSE_KEY from the same ESO secret (server-external-secrets/server-license-key) the server Deployment and migrate Job already use.

Why — root cause

Tuist.License.assert_valid!/0 is called unconditionally at boot (application.ex:57, right after the supervision tree starts) for every non-dev/test release. It reads the key via Environment.license_key/0, which is env-first then falls back to the encrypted blob.

The server Deployment and migrate Job include tuist.licenseEnv, so they get TUIST_LICENSE_KEY explicitly. The two processor deployments never did — they relied on the blob’s license.key. #11460 removed the blob (decrypt_secrets/0 now returns %{}), so license_key/0 is nil → get_license returns :license_not_found → assert_valid! raises:

The license key exposed through the environment variable TUIST_LICENSE or TUIST_LICENSE_KEY is missing.

The build processor (TUIST_MODE=processor) crashloops on boot; the xcresult processor would hit the same once scheduled. This is the same class as the migrate-Job S3 regression (#11545): a release that booted via the blob, never wired explicitly.

Why this solution / scope

Boot-only fix. On the crashing pod the supervision tree (Repo, ClickHouse, Oban, buffers) starts successfully — only the post-start assert_valid!() fails — so wiring the license is sufficient to make the pods boot Ready and unblock the rollout. The processors are also missing some web-tier env helpers the server has (googleEnv, stripePricesEnv, mailingEnv, kuraIntrospectionEnv); those are not boot-critical (they’d surface as individual job failures, not a crashloop), so they’re intentionally out of scope here and can be added if a processor job needs them.

Impact

• Managed deploys: build + xcresult processors boot again; the production cascade is unblocked.
• Self-hosted: tuist.licenseEnv only emits TUIST_LICENSE_KEY when a license source is configured (server.externalSecrets.license.item or server.license.key), so no change for setups without one.

Validation

helm template (managed values) of both deployments now renders:

- name: TUIST_LICENSE_KEY
  valueFrom:
    secretKeyRef:
      name: "tuist-tuist-server-external-secrets"
      key: server-license-key

Discovered live on the canary rollout: the processor pod crashed with the license error above immediately after Tuist application started; the server pod (which has licenseEnv) booted fine on the same image.

🤖 Generated with Claude Code

No GitHub comments yet.