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 26s
__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:38 -05:00
parent a3aed377e0
commit a5486c2ad5
3 changed files with 34 additions and 8 deletions

View File

@@ -24,10 +24,17 @@ diseño** — si tu app necesita base de datos, migra al shape
│ ├── pyproject.toml │ ├── pyproject.toml
│ ├── requirements.txt │ ├── requirements.txt
│ └── Dockerfile │ └── Dockerfile
├── helm/__APP_NAME__/ ← Helm chart minimal (sin hooks) ├── helm/__APP_NAME__/ ← Helm chart minimal
└── .gitea/workflows/ ← CI: tests + build + deploy └── .gitea/workflows/ ← CI: tests + build + deploy
``` ```
> **Hooks Helm:** el `ServiceAccount` se materializa como hook
> `pre-install,pre-upgrade` (`hook-weight: -5`,
> `hook-delete-policy: before-hook-creation`) por **paridad** con el shape
> `web-backend/python`. Este shape no tiene Job de migración, así que el hook
> no es estrictamente necesario aquí — se mantiene para que ambos charts sean
> coherentes. `helm upgrade --install` funciona sin `--no-hooks`.
--- ---
## Endpoints obligatorios ## Endpoints obligatorios

View File

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

View File

@@ -0,0 +1,21 @@
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 por
# PARIDAD con el shape web-backend/python. Este shape NO tiene Job Alembic,
# asi que el hook no es estrictamente necesario aqui — pero mantener ambos
# charts coherentes reduce la carga cognitiva en debugging y onboarding, y
# deja preparado el orden de hooks si en el futuro se agrega un hook que
# dependa del SA. Con hook-weight "-5" el SA se aplica antes que cualquier
# hook con weight >= 0.
"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