El espejo a ASI dejo de correr en cada deploy a dev: push-to-gcaba.sh vuelve a ser manual y ahora puede fallar
Elazar 2026-09-06 (relevado por coder02-mba-l-cc): 'push to gcaba should not happen, only when we wish to push to POD, thus it should be removed'. Se borro .gitdeploydev-post.sh (8eb64a00, v5.4.244); gitdeploydev.sh solo corre el hook si existe y es ejecutable, asi que el paso 6/6 dejo de existir sin tocar el wrapper. Motivo medido: el host repositorio-asi.buenosaires.gob.ar resuelve (200.16.89.97) pero no acepta TCP 443 desde lezama, y el push no tenia connect timeout: cada bump de cada carril pagaba 136 s muertos y el hook salia 128, con lo que gitdeploydev.sh imprimia FAILED sobre un deploy que ya estaba en pie. Deploy completo despues: 46 s (antes ~190 s). push-to-gcaba.sh queda como camino MANUAL con preflight de conexion (5 s), timeout en el push y exit 1 si no espejo nada. CAMBIO DE COMPORTAMIENTO FUERA DEL DIFF: deploy-pod.sh:9 es 'exec ./push-to-gcaba.sh --movilba-only', asi que el exit code de push-to-gcaba.sh ES el de deploy-pod.sh. Un POD que no espejo nada ahora sale 1 en vez de 0. Intencional y confirmado: el cuerpo entero de deploy-pod.sh es el espejo. Docs corregidas en v5.4.245 (9343b5a7): docs/reference/tagging-convention.md:49 decia que lo corre el post-hook de gitdeploydev. Revisadas y NO stale: docs/upgrade.md y docs/tekton/movilba-dev-autotrigger.yaml lo describen como paso manual de una promocion, que sigue siendo cierto. PENDIENTE Y NO MIO: agents/db-mba-l/db-map.md:200 sigue diciendo 'Runs as part of gitdeploydev.sh post-push step'. Es de db-mba-l. ABIERTO, no bloquea: nadie midio si la ruta a ASI deberia funcionar, ni si algo consume la rama develop.
Activity
-
LAZO ABIERTO, sin dueño: agents/db-mba-l/db-map.md:200 sigue diciendo que push-to-gcaba.sh corre en el post-push de gitdeploydev.sh. Eso ya no existe. Handoff ofrecido a db03-mba-l-ca el 2026-09-06; declinado: deja el archivo sin tocar hasta que lo pida el dueño de la documentacion de DB o Elazar. No lo edito yo porque es del carril db. Queda una sola linea stale y esta acotada: describe un hook borrado, no una operacion viva.
-
coder03assistant-mba-l-ca
-
researcher-mba-l-cc / solo
-
Researcher started at 2026-10-08T12:07:26-03:00.
-
researcher-mba-l-cc Entirely superseded by MOVILBA-577. push-to-gcaba.sh no longer exists as a separate script - folded into mba-deploy-pod.sh, which already has: preflight DNS/TCP check with connect-timeout (GCABA_CONNECT_TIMEOUT), push-timeout (GCABA_PUSH_TIMEOUT), and exit 1 on failure - exactly the preflight/timeout fix this ticket asked for, already built. Target host also changed: repositorio-asi.gcba.gob.ar (NEW instance, MOVILBA-577), not the old buenosaires.gob.ar host this ticket's connectivity problem was about. Both "ABIERTO, no bloquea" items resolved by reading the current script: (1) ASI path reachability - mba-deploy-pod.sh's own preflight check answers this at run time now, by design, not by a one-off measurement. (2) develop branch consumption - confirmed consumed: line 163 POSTs to the Tekton EventListener with `"ref":"refs/heads/develop"` after the force-push, triggering the pod build. Not unused. The one "PENDIENTE Y NO MIO" item (agents/db-mba-l/db-map.md:200 stale line) is moot: that whole directory was archived to docs/agents-archive-2026-09-28/db-mba-l/ under MOVILBA-602's prune. No live doc carries the stale claim. Nothing left to do. Closing.
-
Superseded by MOVILBA-577 (new GCABA host + mba-deploy-pod.sh unification); preflight/timeout already built, develop-branch consumption and db-map.md staleness both resolved as side effects of other shipped work. Closed, no code change.