Irving López
1f2eb2f908
Sincroniza desde el monorepo IDP la corrección del hook-order del ServiceAccount (hook pre-install/pre-upgrade, weight -5) que destraba el helm install del golden-path sin --no-hooks. Cierre del 4º gap del pipeline tenant hands-off: el smoke E2E valida ahora la cadena completa (addon-provisioner materializa MariaDB; AddonClaim publica DATABASE_URL en apps). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
25 lines
1.2 KiB
YAML
25 lines
1.2 KiB
YAML
apiVersion: v1
|
|
kind: ServiceAccount
|
|
metadata:
|
|
name: {{ .Release.Name }}
|
|
labels:
|
|
{{- include "app.labels" . | nindent 4 }}
|
|
annotations:
|
|
# El ServiceAccount se materializa como hook pre-install/pre-upgrade para
|
|
# romper el chicken-and-egg con el Job Alembic:
|
|
# - El Job (job-alembic-upgrade.yaml) corre como hook pre-install/pre-upgrade
|
|
# con hook-weight "0" y declara `serviceAccountName: {{ .Release.Name }}`.
|
|
# - Si el SA viviera en la fase principal de Helm se crearía DESPUES del
|
|
# hook → el pod del Job nunca arranca ("serviceaccount not found") →
|
|
# `helm --wait` hace timeout → `helm install` falla.
|
|
# Solucion: el SA es hook con hook-weight "-5" (< "0" del Job) → Helm lo
|
|
# aplica antes que el Job. Asi `helm upgrade --install` funciona sin
|
|
# `--no-hooks`.
|
|
"helm.sh/hook": pre-install,pre-upgrade
|
|
"helm.sh/hook-weight": "-5"
|
|
# before-hook-creation (NO hook-succeeded): el Deployment de la fase
|
|
# principal referencia este SA en runtime — debe seguir vivo tras el hook.
|
|
# before-hook-creation lo borra y recrea solo al inicio del proximo hook,
|
|
# haciendo el SA-hook idempotente entre upgrades sin dejarlo huerfano.
|
|
"helm.sh/hook-delete-policy": before-hook-creation
|