idp-templates/template-web-backend-python
Template
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Activity

docs(readme): nota de serialización/recuperación del deploy + fix drift timeout 7m->10m

Browse Source 
Espeja el fix de CI del repo IDP (TENANT-BUILD-NO-CONCURRENCY-GUARD).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Irving Lopez
2026-06-14 17:11:35 -05:00
parent 569ca5ac8e
commit c8feac5ca7
1 changed files with 12 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
README.md
View File

@@ -7,6 +7,11 @@ Alembic, frontend estático en `/demo`, Helm chart, workflow de CI y manifiesto
de contrato con la plataforma. Cuando se materializa este template para tu de contrato con la plataforma. Cuando se materializa este template para tu
tenant, los placeholders en mayúsculas se sustituyen automáticamente. tenant, los placeholders en mayúsculas se sustituyen automáticamente.
> **Página de bienvenida:** al provisionarse, tu plataforma sirve una página de
> bienvenida en `/` con instrucciones de uso. **En cuanto hagas tu primer
> `commit` + `push`, tu desarrollo reemplaza esa página** — define tu propio
> handler de `/` (en `code/app/main.py` o en `code/app/routers/`).
> **Contrato del shape:** ver `coralware-shape.yaml` en la raíz. Define los > **Contrato del shape:** ver `coralware-shape.yaml` en la raíz. Define los
> endpoints obligatorios, la BD esperada y la versión del shape. No elimines > endpoints obligatorios, la BD esperada y la versión del shape. No elimines
> ese archivo — la plataforma lo lee. > ese archivo — la plataforma lo lee.
@@ -60,7 +65,13 @@ El workflow del tenant sigue este orden en cada `git push`:
|------|--------|--------| |------|--------|--------|
| 1 | `bash scripts/pre-helm-detach.sh` | Migración chart 1.0.0 → 1.1.0: si el AddonClaim tiene labels/annotations de un release Helm previo, las quita. Idempotente: skip si no aplica. Sunset tras ~2 semanas. | | 1 | `bash scripts/pre-helm-detach.sh` | Migración chart 1.0.0 → 1.1.0: si el AddonClaim tiene labels/annotations de un release Helm previo, las quita. Idempotente: skip si no aplica. Sunset tras ~2 semanas. |
| 2 | `kubectl apply -f manifests/addonclaim.yaml` (con `sed` para placeholders) | Crea o actualiza el `AddonClaim`. Idempotente. `addon-provisioner` empieza a reconciliar en paralelo. | | 2 | `kubectl apply -f manifests/addonclaim.yaml` (con `sed` para placeholders) | Crea o actualiza el `AddonClaim`. Idempotente. `addon-provisioner` empieza a reconciliar en paralelo. |
| 3 | `helm upgrade --install <release> ./helm/<APP_NAME> --wait --timeout 7m` | Aplica el chart Helm. Los hooks `pre-install,pre-upgrade` corren en orden de `hook-weight` (ver tabla abajo). El Job Alembic espera al Secret. | | 3 | `helm upgrade --install <release> ./helm/<APP_NAME> --wait --timeout 10m` | Aplica el chart Helm. Los hooks `pre-install,pre-upgrade` corren en orden de `hook-weight` (ver tabla abajo). El Job Alembic espera al Secret. |
> **Deploys serializados + auto-recuperación:** el workflow tiene un guard
> `concurrency` por repo, así que dos `git push` seguidos se **encolan** (no corren
> el `helm upgrade` en paralelo). Si un deploy quedó a medias (cancelado), el
> siguiente run **detecta y recupera** el release atascado (`pending-install` →
> reinstala; `pending-upgrade` → rollback) antes de reintentar.
El chart usa hooks `pre-install,pre-upgrade` con `hook-weight` para garantizar El chart usa hooks `pre-install,pre-upgrade` con `hook-weight` para garantizar
el orden de creación de SUS recursos (sin AddonClaim — ese vive fuera). el orden de creación de SUS recursos (sin AddonClaim — ese vive fuera).