db-map.md:200 dice que el espejo a GCABA corre en cada deploy: se borro el post-hook y el punto de entrada vivo es deploy-pod.sh
agents/db-mba-l/db-map.md:200 describe push-to-gcaba.sh como que 'Runs as part of gitdeploydev.sh post-push step'. Desde el 2026-09-06 eso es FALSO: por decision de Elazar el espejo a GCABA salio del camino automatico y .gitdeploydev-post.sh se BORRO (v5.4.244, 8eb64a00). El unico punto de entrada vivo es deploy-pod.sh, que hace exec de push-to-gcaba.sh --movilba-only y por lo tanto ADOPTA su exit code; ese exit code cambio de 0 a 1 cuando no se espejo nada, intencional y confirmado por coder03-mba-l-cc, porque un POD que no espejo nada es un POD que no se deployo. Queda registrado en MOVILBA-297. QUE HAY QUE HACER: corregir esa linea de db-map.md para que nombre a deploy-pod.sh como el punto de entrada y diga que el espejo es MANUAL. El archivo es de db-mba-l, carril que no esta entregando; se asigna a db03-mba-l-ca como carril db vivo. CONTEXTO DE POR QUE SE SACO: la llamada era un git push --force sin timeout a repositorio-asi.buenosaires.gob.ar, que resuelve a 200.16.89.97 pero nunca acepta TCP 443. Bloqueaba 136 segundos en CADA deploy a dev, de CADA carril, en CADA bump, despues de que el deploy ya habia terminado bien - y ademas marcaba el deploy con exit 4 por 'remoto de sync atrasado'. El deploy paso de ~190s a 46s. LO QUE NO HAY QUE HACER: recrear .gitdeploydev-post.sh. gitdeploydev.sh lo invoca con [[ -x .gitdeploydev-post.sh ]] en la linea 709, asi que basta con que el archivo exista y sea ejecutable para que el paso 6/6 vuelva solo. NO EJERCITADO: nadie midio si la ruta de red a ASI esta muerta por diseno o caida (nw-lezama-cc no la sondeo), y nadie establecio que consume la rama develop. Las dos preguntas siguen abiertas y ya no bloquean nada del camino de deploy. coder03-mba-l-cc leyo docs/upgrade.md y docs/tekton/movilba-dev-autotrigger.yaml y NO estan stale: ahi el espejo ya se describe como paso manual.
Activity
-
OJO CON LA CITA: la descripcion de este item dice 'queda registrado en MOVILBA-297' porque copie la frase del mensaje de coder03-mba-l-cc, que cito ese numero ANTES de que existiera. El numero cayo en este item, que es sobre db-map.md, NO sobre el cambio de exit code de deploy-pod.sh. El cambio de exit code esta confirmado por coder03-mba-l-cc en el canal y queda asentado ACA, en este evento: push-to-gcaba.sh pasa de 0 a 1 cuando no espejo nada, y como deploy-pod.sh hace exec, ese exit code es el suyo. Intencional. No hay otro item que lo lleve.
-
db03-mba-l-cc
-
db02-mba-l-cc
-
VERIFICADO, Y APARECIO ALGO QUE NO ES DOCUMENTACION - db02-mba-l-cc, 2026-09-12, SOLO LECTURA. 1. LA LINEA DEL DOC SIGUE MAL, confirmado: agents/db-mba-l/db-map.md, entrada de push-to-gcaba.sh, termina con 'Runs as part of gitdeploydev.sh's post-push step.' Esta igual en el checkout compartido y en origin/dev. La correccion que pide el item sigue pendiente y es la misma que describe: nombrar deploy-pod.sh como punto de entrada y decir que el espejo es MANUAL. 2. LO QUE NO ES DOCUMENTACION Y HAY QUE MIRAR HOY: .gitdeploydev-post.sh EXISTE Y ES EJECUTABLE en el checkout compartido /home/rob/Documents/work/gcaba/movilba-web. - No esta en origin/dev ni en origin/main: ahi fue borrado, como dice el item. - PERO el checkout compartido esta parado en la rama movilba-97-modification-subtype, y en el HEAD de ESA rama el archivo sigue trackeado y presente. git status lo da limpio, o sea no es un residuo sin commitear: es contenido de la rama. - Su cuerpo hace exec de ./push-to-gcaba.sh --movilba-only, que es exactamente la llamada bloqueante que se saco del camino. - Y el propio item avisa que gitdeploydev.sh lo invoca con [[ -x .gitdeploydev-post.sh ]]. La condicion se cumple hoy en ese checkout. CONSECUENCIA: cualquier deploy a dev lanzado desde ese checkout mientras este en esta rama vuelve a colgar 136 segundos contra repositorio-asi y vuelve a marcar el deploy con exit 4. El borrado protege a quien deploya desde dev; no protege a quien deploya desde una rama anterior al borrado. NO LO TOQUE: es un archivo trackeado de una rama ajena y borrar no esta autorizado. Es trabajo de un carril de codigo decidir si esa rama se rebasea sobre dev, si el archivo se borra tambien ahi, o si el guard va adentro de push-to-gcaba.sh en vez de depender de que el archivo no exista. Y esa ultima es la unica que cierra la clase: mientras la condicion sea 'que el archivo no exista', cada rama vieja y cada worktree es una reaparicion. 3. Sigue sin ejercitar lo que el item ya marcaba como abierto: nadie sondeo la ruta a ASI y nadie establecio que consume develop. No agrego nada ahi. Nada ejecutado, nada borrado, nada editado.
-
MEDICION SOBRE LA MITIGACION - db02-mba-l-cc, 2026-09-12, SOLO LECTURA, nada escrito ni borrado por este carril. coder02-mba-l-cc hizo chmod -x sobre la copia de working tree de .gitdeploydev-post.sh en el checkout compartido. Medido lo que eso significa realmente: 1. EL BIT DE EJECUCION ESTA EN EL ARBOL DE GIT, NO EN EL DISCO. git ls-tree HEAD da 'mode 100755 blob 5a50c732' para ese path en movilba-97-modification-subtype. Con core.fileMode=true, el chmod aparece como modificacion trackeada: 'old mode 100755 / new mode 100644'. O sea es un estado sucio de ESE working tree, no una propiedad de la rama. 2. CONSECUENCIA: cualquier git checkout, cambio de rama, stash pop, reset --hard, clon nuevo o worktree nuevo restituye 100755. Y cualquier OTRO checkout de esta rama nunca vio el chmod. La mitigacion vale para un solo directorio y hasta la proxima operacion de git que toque ese path. 3. NO PUDE CONFIRMAR EL PREDICADO DE LA GUARDA. gitdeploydev.sh vive en sh.git, fuera del limite de lectura de este proyecto, que me aplica igual que a coder02. La unica fuente de '[[ -x .gitdeploydev-post.sh ]] en la linea 709' es la descripcion de ESTE item, o sea un relato, no una medicion. Si el predicado fuera -f, el chmod no hace absolutamente nada. Lo dirime en un grep el carril que ownea sh.git (bin-lezama-cc). Hasta entonces la mitigacion es condicional a un dato no verificado. RESUMEN HONESTO DEL ESTADO: es una RETENCION, no un arreglo, y depende de un predicado sin medir. No debe reportarse como cerrado. Y sigue en pie lo del apunte anterior: borrar el archivo en esta rama tampoco cierra la clase, porque se repite en cada rama anterior al borrado y en cada worktree viejo. El unico arreglo durable es la salida temprana adentro de push-to-gcaba.sh, que viaja con todas las refs.
-
PREDICADO MEDIDO, Y UNA CORRECCION SOBRE LO QUE SE PUEDE COMMITEAR - db02-mba-l-cc, 2026-09-12. 1. MEDIDO por bin-lezama-cc, que es el carril que ownea sh.git: gitdeploydev.sh linea 762, 'if [[ -x .gitdeploydev-post.sh ]]; then'. El predicado es -x, como decia la descripcion de este item. El NUMERO DE LINEA de la descripcion esta vencido: dice 709, es 762. Corregir esa cita cuando se toque el item - una cita con numero de linea se lee como evidencia dura y esta envejeciendo sola. Con eso, la retencion por chmod -x que hizo coder02 SI vale, con el alcance ya medido: ese working tree, hasta la proxima operacion de git que restituya 100755 desde el arbol. 2. CORRECCION A UNA AFIRMACION QUE QUEDO EN EL HILO, y la dejo aca en vez de reabrirlo: se dijo que 'gatear por el bit de ejecucion significa que el desarme no se puede commitear como contenido, solo como cambio de modo, asi que no-ejecutable nunca es un estado durable de la rama'. La primera mitad es cierta, la conclusion no. El modo ESTA en el arbol de git - por eso git ls-tree devuelve 100755 y por eso el chmod aparece como 'old mode 100755 / new mode 100644' en git diff. Un cambio de modo se commitea igual que cualquier otro cambio, y una vez commiteado 100644 SI es un estado durable de esa rama: sobrevive a checkout, clon y worktree nuevo. Por que importa en la practica: existe un desarme intermedio mas barato que borrar el archivo trackeado - commitear el cambio de modo en la rama. No cierra la clase (cada OTRA rama anterior al borrado sigue con 100755, y ahi el argumento de la salida temprana en push-to-gcaba.sh sigue siendo el unico arreglo durable), pero es una opcion real que la afirmacion de arriba descarta por error, y decidir con una opcion de menos es peor que decidir. Este carril no escribio, no borro y no commiteo nada.
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 03:56 ART. Current tracked agents/db-mba-l/db-map.md lines 192-196 says old push-to-gcaba.sh and post hooks were removed and mba-deploy-pod.sh is the manual GCABA mirror entrypoint; no dev deploy triggers it. git log -1 for this file is f90ef53a (2026-09-17), and the file has no working-tree modification. The requested documentation correction is present in the repository.