sync: GOLDEN-PATH-CHART-HOOK-ORDER + ADDON-PROVISIONER-IMPL — desde coralware/IDP@9f03643
Some checks failed
__APP_NAME__ — build & deploy / Calidad + build + push (push) Failing after 27s
__APP_NAME__ — build & deploy / Helm upgrade --install (push) Has been skipped

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>
This commit is contained in:
2026-05-22 16:56:36 -05:00
parent bd12f2d0f9
commit 1f2eb2f908
3 changed files with 53 additions and 7 deletions

View File

@@ -67,13 +67,11 @@ spec:
- name: tmp
emptyDir: {}
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: {{ .Release.Name }}
labels:
{{- include "app.labels" . | nindent 4 }}
---
# El ServiceAccount {{ .Release.Name }} NO se define aqui — vive en
# serviceaccount.yaml como hook pre-install/pre-upgrade (hook-weight "-5") para
# garantizar que exista antes del Job Alembic. El Deployment lo referencia en
# `serviceAccountName` y el SA-hook usa `hook-delete-policy: before-hook-creation`
# para no quedar huerfano entre upgrades.
apiVersion: v1
kind: ConfigMap
metadata:

View File

@@ -0,0 +1,24 @@
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