Propaga desde coralware/IDP@b31c741 (CI-SHARED-HOME-RACE). El step usa el helm
pre-horneado de la imagen del runner si está presente; el fallback descarga a un
dir único por-run (mktemp), nunca a $HOME/.local/bin ni /tmp/linux-$ARCH
compartidos que con executor=host se pisan entre jobs concurrentes.
Sin guard `concurrency:` múltiples dispatches del repo del tenant corrían
helm upgrade en paralelo sobre el mismo release → 'another operation in
progress' → release trabado en pending-install → primer deploy nunca completa
(vivido E2E 2026-06-10, tenant 9e6babb0). Causa raíz del first-deploy flaky
(runs 3418/3419).
- concurrency workflow-level (group por repo, cancel-in-progress:false: encola,
no cancela — cancelar a mitad de helm install es lo que CREA el pending-install)
- step de recuperación: detecta pending-install/uninstalling→uninstall,
pending-upgrade/pending-rollback→rollback, antes del helm upgrade. Fail-safe:
solo toca estados pending-*, no toca deployed/failed/inexistente.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Además: añadido el wait de rancher-webhook (RANCHER-WEBHOOK-RACE-RECOVERY) que
faltaba en rest-api — paridad con el template web-backend.
E2E 2026-06-05 mostró que en template mínimo la calidad corre ~15s, así que el
build alcanza 'Build y push a Harbor' antes de que tenant-manager fase 1 siembre
(~20s) → run #1 rojo. build-gate (1er job) skipea el build si HARBOR_ROBOT_USER
ausente, simétrico al cluster-gate. El dispatch de fase 2 hace el run completo.
Sync desde coralware/IDP.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Job cluster-gate -> helm-deploy con if needs.cluster-gate.outputs.ready=='true'.
Sin KUBECONFIG_TENANT_B64 (cluster aprovisionando) el deploy queda SKIPPED, no
rojo. tenant-manager (fase 2 deploy-ready) dispara workflow_dispatch al sembrar
el kubeconfig -> run #2 despliega. Sincronizado desde coralware/IDP commit a27e153.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
Workflow <app>-build.yaml self-contained — sin uses: cross-repo al repo
privado coralware/IDP. requirements-dev.txt inline. image.repository apunta
al proyecto Harbor dedicado del tenant t-<tenant-id-short> (ADR-019 D-03).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- workflow: --namespace apps (antes tenant-${TENANT_ID_NODASHES}-apps)
ADR-054 establece namespaces funcionales en cluster tenant. El cluster
RKE2 dedicado ya es el sandbox del tenant.
Reemplaza el placeholder mínimo previo por el scaffold canónico del
golden path rest-api/python (entry point para tier free-trial):
- code/app/main.py — FastAPI con /health (sin DB), /metrics, middleware
correlation_id, settings Pydantic
- code/tests/ — pytest + httpx TestClient (sin testcontainers, sin Docker)
- helm/APP_NAME/ — chart minimal: Deployment, Service, IngressRoute,
NetworkPolicy. SIN Job Alembic, SIN ServiceMonitor, SIN claim de BD
- coralware-shape.yaml — shapeVersion 1.0.0, minTier free-trial,
promotionPath -> web-backend-python cuando se requiera persistencia
- .gitea/workflows/APP_NAME-build.yaml — invoca reusable workflow ADR-038
+ job helm-deploy con KUBECONFIG_TENANT_B64
Diferencias con web-backend/python: sin alembic, sin BD, sin
testcontainers, NetworkPolicy sin acceso a ns-addons.
Placeholders __APP_NAME__, __TIER__, __TENANT_ID__, __TENANT_ID_NODASHES__
serán sustituidos server-side por repo-provisioner.
El openspec/ del golden path NO se sincroniza al repo Gitea (gobernanza
interna de Coralware).
Refs: ADR-027 (Golden Paths), ADR-038 (CI), ADR-053 (referencia anatomía).
