El step 'Recuperar release Helm atascado' (TENANT-BUILD-NO-CONCURRENCY-GUARD,
6bb3a35) muere en la asignación STATUS=$(helm status ...) cuando el release no
existe (first-deploy frío): helm sale exit≠0, pipefail lo propaga y set -e aborta
el step ANTES del case → deploy job rojo → app nunca instala → welcome 404.
Fix: || true neutraliza el exit → STATUS="" → branch no-op → helm upgrade procede.
Regresión introducida por el propio fix de CI-SHARED-HOME-RACE; detectada en el
re-smoke E2E 2026-06-17.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
Job cluster-gate -> helm-deploy con if needs.cluster-gate.outputs.ready=='true'.
Sincronizado desde coralware/IDP commit a27e153.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sync del fix ADDON-PROVISIONER-DB-SECRET-NOT-PUBLISHED (IDP P0).
Ver IDP commit 673c16d para contexto completo.
El init container wait-for-secret del Job Alembic ahora espera 72×5s=360s
(antes 48×5s=240s), dimensionado a 3× el RECONCILE_INTERVAL del
addon-provisioner. El controller bajó su default 300s → 60s en el mismo
parche.
Defense-in-depth: con el controller corriendo a 60s, el delay típico
del Secret publish es ~60-180s. Los 360s del init container absorben
hasta 3 ticks fallidos del controller (cluster recién Ready, kubeconfig
no propagado, etc.).
helm timeout 7m → 10m para que el wait extendido del init container
+ Alembic + StatefulSet ready quepan dentro del comando helm.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Race condition durante el bootstrap del cluster tenant: el rancher-webhook
Deployment en cattle-system aún no tiene endpoints cuando el primer
helm upgrade --install intenta crear el namespace apps, lo que dispara
el webhook rancher.cattle.io.namespaces.create-non-kubesystem y aborta
el release con "no endpoints available for service rancher-webhook".
El re-dispatch ~5-10min después recuperaba natural, pero degrada el
smoke E2E. Espera explícita (kubectl wait deployment rancher-webhook
--for=condition=Available --timeout=600s) evita el flake.
Origen: smoke E2E 2026-05-25 run #1550 (chart 0.3.0 ADR-066 validación).
Sincronizado del IDP monorepo.
Bug en chart 0.2.x: AddonClaim era Helm hook pre-install,pre-upgrade
weight -10 SIN hook-delete-policy. El default Helm 3 es
before-hook-creation → borra el claim en cada upgrade → finalizer
cleanup-logical rotaba credenciales + atoraba release en pending-upgrade.
Cambios:
- helm/APP_NAME/templates/addonclaim.yaml eliminado.
- manifests/addonclaim.yaml creado con placeholders sed.
- scripts/pre-helm-detach.sh idempotente para migracion v1.0.0 → 1.1.0.
- .gitea/workflows/APP_NAME-build.yaml: 2 nuevos steps detach + apply
AddonClaim entre kubeconfig y helm upgrade.
- Chart.yaml bump 0.2.0 → 0.3.0.
- README reescrito (3 pasos workflow + tabla hooks sin AddonClaim +
seccion Por que FUERA del chart + opt-out actualizado).
- Comentarios stale del AddonClaim como hook -10 limpiados en
networkpolicy.yaml, role-db-secret-reader.yaml, job-alembic-upgrade.yaml.
ADR-066 del IDP documenta la decision arquitectural completa.
Cierra GOLDEN-PATH-ADDONCLAIM-MISSING (P0 hands-off pipeline).
Cambios:
- helm/APP_NAME/templates/addonclaim.yaml (NEW): hook pre-install/pre-upgrade
weight -10, SIN delete-policy (sobrevive upgrades, evita disparar finalizer
cleanup-logical). Gated por .Values.database.enabled (default true).
- helm/APP_NAME/templates/role-db-secret-reader.yaml (NEW): Role + RoleBinding
weight -7 que permite al SA leer el Secret <release>-db-creds. Lo consume
el InitContainer wait-for-secret del Job Alembic.
- helm/APP_NAME/templates/job-alembic-upgrade.yaml: gated por
database.enabled, anade InitContainer wait-for-secret (48x5s=240s) que
espera a que addon-provisioner publique el Secret tras reconciliar el
AddonClaim. Absorbe la latencia del @kopf.timer (RECONCILE_INTERVAL 300s
+ initial_delay 60s) sin tocar el operator.
- helm/APP_NAME/values.yaml: bloque database completo (enabled, addonType,
databaseName, user.permissions, deletionPolicy Retain). Opt-out con
database.enabled=false + alembic.enabled=false.
- .gitea/workflows/APP_NAME-build.yaml: helm timeout 5m -> 7m (margen para
reconcile addon-provisioner + StatefulSet ready + DDL Job + Alembic).
- claim-mariadb.yaml (DELETED): obsoleto - estaba en la raiz del template
y nunca se renderizaba por helm. Reemplazado por addonclaim.yaml dentro
del chart helm.
- README.md: documenta nueva tabla de hook weights, opt-out database, y
trade-off del orphan AddonClaim post-uninstall (cleanup explicito).
Decision arquitectural: Opcion D modificada (Opus 4.6 consult).
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>
El job helm-deploy declaraba container: alpine/helm:3.14.4. Los runners de
ci-system corren con container.enabled=false (executor=host, ADR-043): sin
Docker daemon, cualquier job con container: falla al arrancar con 'Cannot
connect to the Docker daemon' antes de ejecutar step alguno (mismo patron
que SMOKE-COVE-WORKFLOW-CONTAINER-FIX).
Fix: se elimina container:; el job corre directo sobre el runner host.
kubectl ya viene en la imagen del runner; helm se instala en runtime via
curl (la NetworkPolicy de los runners permite egress 443). kubeconfig al
HOME del runner en vez de /root.
GOLDEN-PATH-WEBBACKEND-DRYRUN.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- workflow: --namespace apps (antes tenant-${TENANT_ID_NODASHES}-apps)
- values.yaml networkPolicy.addonsNamespace: addons (antes con tenant-id)
ADR-054 establece namespaces funcionales en cluster tenant (RKE2 dedicado
por ADR-018). El cluster es la unidad de aislamiento; tenant-id en
namespace name es legacy del modelo multi-tenant en cluster compartido.
