Medir el camino de deploy antes de consolidar remotos

Sub-tickets

Activity

• wi-cli-venus created · 3w ago
• wi-cli-venus note · 3w ago
  Primera evidencia medida, salida del deploy de MOVILBA-530 el 2026-09-22 06:35 (no se salio a buscarla, aparecio sola): mba-deploy-dev.sh NO empuja al remoto 'lezama'. Su propia salida dice 'Pushed to dev' y 'origin: sync OK' - dos remotos, no tres. Medido con git ls-remote <remoto> refs/heads/dev justo despues del push: dev 7037996d origin 7037996d lezama 8f30bfaa lezama esta TRES commits atras y ya lo estaba antes de este cambio: tampoco tiene b52c8b62 (MOVILBA-498) ni 4455df50 (MOVILBA-224). O sea que no es un push que fallo hoy, es un remoto que el script no alimenta y que viene quedandose atras hace por lo menos dos deploys. Esto parte la pregunta de los remotos en dos, y hay que contestar la primera antes de tocar nada: (a) para que existe lezama/dev y quien lo lee. Si algo lo consume, esta sirviendo codigo de hace tres commits y eso es un defecto AHORA, no una consolidacion pendiente. Si no lo lee nadie, es candidato a borrar. (b) recien despues: si origin y dev son dos caminos con un solo rol, cual sobra. Ojo con la asimetria: 'lezama' tambien tiene refs/heads/main. Medir los dos, no solo dev. Sigue faltando lo principal del item: la tabla push autoritativo -> build -> health/version -> rollback que pidio coder02 como condicion para borrar cualquier camino.
• wi-cli-venus note · 3w ago
  RETRACTO la evidencia del 06:35. El hallazgo 'mba-deploy-dev.sh no empuja a lezama' era una mala comparacion mia, no un defecto. Lo que medi mal: compare lezama/dev contra dev/dev y lo llame atraso. Nunca lei que es el remoto 'lezama'. git remote -v, medido: dev /srv/dev-movilba-web.git -> dev.movilba.com lezama /srv/movilba-web.git -> app.movilba.com (PROD) staging /srv/staging-movilba-web.git -> staging origin https://github.com/ElazarPimentel/movilba-web.git Tres son bare repos LOCALES en esta misma maquina; solo origin es remoto de verdad. El nombre 'lezama' no es un host al que se empuja: lezama es el host donde corre todo esto. El remoto 'lezama' es el bare de PRODUCCION - el header de mba-deploy-prod.sh lo dice literal: 'TARGET: app.movilba.com (lezama bare /srv/movilba-web.git, branch main)', y empuja main ahi (linea 64) mas origin/main (linea 68). Entonces lezama/dev tres commits atras NO es drift y NO es un push faltante: nada sirve desde lezama/dev. mba-deploy-dev.sh empuja a dev + origin (lineas 172 y 176) y eso es correcto; el bare de prod solo recibe main. Compare una rama de la que nadie deploya. Que queda del item despues de esto: la premisa de consolidacion se cae casi entera. Cuatro remotos con cuatro roles distintos y no solapados - dev, prod, staging, GitHub - no son tres caminos redundantes de un solo pusher. Lo unico que sobrevive para medir: (a) refs/heads/dev en el bare de PROD es una ref rancia y huerfana; confirmar que nadie la lee y recien ahi decidir si se borra. Es hygiene, no performance. (b) el bare de staging: nadie midio si algo lo consume todavia. (c) sigue faltando la tabla que pidio coder02: push autoritativo -> build -> health/version -> rollback. Esa parte del item no la toca esta correccion. Leccion: un remoto se lee con git remote -v antes de afirmar nada sobre el, y un nombre de remoto no nombra necesariamente un host.
• wi-cli-venus note · 3w ago
  Elazar, CLI 2026-09-22: STAGING ESTA DECOMISIONADO. El repo todavia tiene el remoto 'staging' -> /srv/staging-movilba-web.git. Queda como candidato a sacar, pero no se toca hasta confirmar que nada lo consume. Mapa de remotos corregido con eso encima: dev /srv/dev-movilba-web.git VIVO, recibe dev lezama /srv/movilba-web.git VIVO, es el bare de PROD, recibe main staging /srv/staging-movilba-web.git DECOMISIONADO segun Elazar origin github.com/ElazarPimentel/movilba-web VIVO, recibe dev y main Pregunta abierta mandada a nw-lezama-cc (tag coder03-mba-l-cc-muchjcx096ka): existe dev.movilba.com de verdad - DNS, vhost/proxy, TLS. El motivo: mba-deploy-dev.sh declara 'TARGET: dev.movilba.com' en su header pero su gate de health consulta http://127.0.0.1:3042/api/health, loopback, nunca el hostname. O sea que el script afirma un nombre publico que nunca verifica. Hasta tener la respuesta no se sabe si ese nombre esta sirviendo o es texto vestigial.
• wi-cli-venus statusChanged · 3w ago
  STARTED MOVILBA-531 at 2026-09-22T06:48:09-03:00. Orden de Elazar por CLI: trabajar 531, arreglar el bug del .next/ y los demas bugs encontrados, y pedirle a audit que revise. MEDICIONES (todas read-only, hechas antes de tocar nada): - next typegen EXISTE en Next 16 y regenera .next/types sin build completo. Corrido en vivo: 'Types generated successfully', despues tsc --noEmit rc=0 y CERO archivos trackeados ensuciados (next-env.d.ts no se movio). Ese es el arreglo de B1. - .next/dev/types nunca se genero en este arbol (tsconfig lo incluye pero no existe). No hay next dev corriendo. No es un segundo peligro hoy. - rob SI esta en el grupo git, y /srv/dev-movilba-web/logs es drwxrwsr-x. El write falla por el MODO DEL ARCHIVO: deploy.log es -rw-r--r-- de movilba_srv, sin bit de grupo. Ultima escritura 2026-08-11. deploy.json en cambio es -rw-rw-r-- de rob y se escribio hoy 06:37. - El bare /srv/dev-movilba-web.git no tiene NINGUNA clave receive.*: acepta non-fast-forward y deletes por default. Un rollback por git push dev <sha-viejo>:dev seria aceptado y re-dispararia el hook. Esa es la celda de rollback de la tabla de coder02. - DEV_DEPLOY_LOG lo consume SOLO mba-deploy-dev.sh. STAGING_REMOTE_NAME, STAGING_REMOTE_URL, STAGING_SERVICE_NAME y PROD_REMOTE_URL no los consume NINGUN script mba-*: es config muerta. - PROD_REMOTE_URL dice rob@app.movilba.com:/srv/movilba-web.git (ssh) pero el remoto real 'lezama' es la ruta local /srv/movilba-web.git. Config muerta Y contradictoria; no rompe nada porque nadie la lee. - vercel.json existe, .vercel no. origin tiene consumidor posible via GitHub, no es solo backup. RESPUESTA DE nw-lezama-cc (tag nw-lezama-cc-muchmw9t0z66), corregida por Elazar: NO existe dev.movilba.com como entorno. dev01.movilba.com es dev y frontea el 3042, esta vivo. app.movilba.com es prod, vivo. dev.movilba.com es solo un stub 308 en Caddy que redirige al POD (permisos-movilba-dev.gcba.gob.ar). El header TARGET de mba-deploy-dev.sh que lo nombra es vestigial. staging.movilba.com sigue teniendo vhost en Caddy apuntando a localhost:3043 pero no hay nada escuchando ni unit de systemd: backend muerto.
• wi-cli-venus progress · 3w ago
  SHIPPED v5.6.3, commit ba27fdd7 en dev + origin, health OK sirviendo patch 3 al primer intento. Tres bugs arreglados en un solo deploy. B1 - .next/ rancio typechequeado como fuente. ARREGLADO en package.json: typecheck pasa de 'tsc --noEmit' a 'next typegen && tsc --noEmit'. next typegen existe en Next 16 y regenera .next/types desde el arbol actual sin build completo. No se borro nada y no se saco '.next/types/**' del tsconfig, asi que la validacion de rutas tipadas se conserva - que es lo que se perdia con la otra salida posible. Verificado en vivo antes de shipear: typegen rc=0, tsc rc=0, cero archivos trackeados ensuciados. Verificado despues: el propio deploy corrio el typecheck nuevo y paso. B2 - el script mentia sobre lo que commiteaba. mba-deploy-dev.sh ataba RUN_PATHS (package.json, lockfiles, CHANGELOG) al pathspec DESPUES de llamar a mba_cs_stage, que es justo la funcion que imprime 'committing exactly these paths' y 'ALSO STAGED but NOT in this commit'. Resultado: anunciaba package.json y los lockfiles como EXCLUIDOS y despues los commiteaba igual. Se vio literal en 7037996d. ARREGLADO moviendo el binding ANTES de mba_cs_stage y extendiendo tambien MBA_CS_PATHS, porque el bloque '_outside' se calcula contra ESA lista y no contra el pathspec. Evidencia del arreglo: el bloque falso 'ALSO STAGED but NOT in this commit' aparecio en las DOS corridas anteriores y NO aparece en esta. De paso se saco un peligro de set -e: '(( ... )) && ...' como sentencia suelta devuelve 1 cuando el array esta vacio (modo staged) y habria matado el script; ahora es un if. B3 - el log de deploy estaba muerto desde el 2026-08-11. No era permiso de directorio: rob SI esta en el grupo git y logs/ es drwxrwsr-x. Era el MODO DEL ARCHIVO - deploy.log era -rw-r--r-- de movilba_srv, sin bit de grupo, asi que el append fallaba y el script tiraba su warning amarillo en cada corrida mientras seis semanas de deploys no dejaban registro. sudo no era usable (pide password, sin askpass, y el unico password a mano es el SUDO_PASSWORD en texto plano del post-receive, que no se toca). Se roto el archivo a mano aprovechando que el DIRECTORIO si es escribible. ARREGLADO: la corrida de v5.6.3 escribio '2026-09-22T06:50:43-0300 OK stage=complete rc=0 v5.6.3 dev->dev', primera linea desde agosto. B4 - el header mentia sobre el destino. 'TARGET: dev.movilba.com' era falso: nw-lezama-cc confirma que ese nombre es solo un stub 308 al pod de OpenShift y que el entorno dev real es dev01.movilba.com. ARREGLADO en el header, nombrando dev01 y diciendo explicitamente que dev.movilba.com NO es esto, para que nadie lo vuelva a 'corregir' al reves. El gate de health que consulta 127.0.0.1:3042 NO se toco: chequear el proceso por loopback es lo correcto para un deploy en el mismo host; lo que estaba mal era el header, no la sonda. usage() imprimia las lineas 2-20 del propio archivo, asi que se corrio a 2-22 y se verifico que el bloque de exit codes sigue saliendo entero. EFECTO COLATERAL QUE HAY QUE DECIR: el post-receive hace git clean de logs/ en el arbol desplegado. El archivo que yo habia preservado, deploy.log.hasta-2026-08-11, lo borro el push siguiente. Su contenido entero, para que no se pierda, era una sola linea: '2026-08-11T15:09:35-0300 OK stage=complete rc=0 v5.3.171 dev->dev sync-skipped=[gcaba]'. Nota de paso: nombra un remoto 'gcaba' que ya no existe. Leccion a memoria: no se guarda nada en /srv/dev-movilba-web/logs/ esperando que sobreviva un push. LIMPIEZA, sin codigo trackeado de por medio: - Se saco el remoto git 'staging'. Doble muerto: Elazar lo declaro decomisionado y ademas /srv/staging-movilba-web.git NO EXISTE en disco. Quedan tres remotos. - .env.local (gitignoreado): se borraron PROD_REMOTE_URL, PROD_SERVICE_NAME, DEV_REMOTE_URL, DEV_SERVICE_NAME y los tres STAGING_*. Medido con grep sobre mba-*.sh, tools/, scripts/ y el post-receive: CERO consumidores, ninguno. Los dos *_REMOTE_URL ademas decian mentira - describian ssh a un hostname cuando los remotos son rutas locales, y DEV_REMOTE_URL nombraba dev.movilba.com, que no es dev. Quedo un comentario diciendo que la verdad se lee de git remote -v.
• wi-cli-venus spec · 3w ago
  TABLA DEL CAMINO DE DEPLOY DE DEV - la condicion que puso coder02 antes de borrar cualquier camino. Medida sobre ba27fdd7 (v5.6.3), salvo donde diga lo contrario. CELDA 1, push autoritativo: 'git push dev HEAD:dev' a /srv/dev-movilba-web.git, bare LOCAL en esta misma maquina. Es el unico push que dispara build. MEDIDO: 7037996d..ba27fdd7. CELDA 2, build: NO lo hace mba-deploy-dev.sh. Lo hace /srv/dev-movilba-web.git/hooks/post-receive, sincronico DURANTE el push - por eso el push se queda callado minutos. Progreso en logs/pnpm-build.log del arbol desplegado. Corolario que ya estaba en memoria y se re-confirma: un abort del script NO implica que el deploy no corrio, porque cualquier push a dev construye. MEDIDO: el push imprimio las lineas remote: y dejo el arbol en ba27fdd7. CELDA 3, health + frescura: http://127.0.0.1:3042/api/health. No alcanza con un 200 - el endpoint publica un serviceId opaco = patch*SVC_K + SVC_C, y el script lee K y C del FUENTE (src/app/api/health/route.ts), nunca copiados al script, y decodifica en CADA reintento porque las primeras sondas pegan al proceso viejo. MEDIDO: 'Health OK, serving patch 3 (attempt 1/10)' con v5.6.3. Esta celda es la unica que prueba que lo que sirve es lo que se empujo, y es load-bearing: se queda. CELDA 4, rollback: NO EXERCITADA, y lo digo asi en vez de darla por buena. Lo unico medido es la config del bare: 'git config -f /srv/dev-movilba-web.git/config --get-regexp receive\.' devuelve VACIO, o sea ninguna clave receive.*, o sea denyNonFastForwards y denyDeletes en su default false. De ahi se INFIERE que 'git push dev <sha-viejo>:dev' seria aceptado y re-dispararia el post-receive, que es la forma del rollback. Inferencia de config, no observacion: nadie vio al bare aceptar un non-fast-forward. Probarlo de verdad es empujar un SHA viejo a dev y revertir el deploy vivo - eso pide la palabra de Elazar, no lo hago de motu propio. CELDA 5, origin: 'git push origin HEAD:dev' a github.com/ElazarPimentel/movilba-web. MEDIDO que llega (origin=ba27fdd7). NO MEDIDO si tiene consumidor de build: existe vercel.json en el repo pero NO existe .vercel, y no verifique contra la API de Vercel. Asi que NO afirmo que origin/dev sea solo backup - queda como pregunta abierta, no como celda verde. Un fallo de este push da rc=2, dev queda desplegado y origin atras. VEREDICTO SOBRE CONSOLIDAR: la premisa se cae. Quedan tres remotos con tres roles no solapados - dev (bare local, entorno dev), lezama (bare local, PROD, recibe main), origin (GitHub). No son tres caminos para lo mismo. El unico que sobraba era staging y ya se fue. COBERTURA: esta tabla cubre el camino de DEV. El camino de PROD (mba-deploy-prod.sh, el bare de prod, app.movilba.com) NO se ejercito ni se midio en este item. PENDIENTE MENOR DE HIGIENE, no urgente: el bare de PROD /srv/movilba-web.git tiene un refs/heads/dev huerfano de hace tres commits del que nadie deploya. Confirmar que nadie lo lee y recien ahi decidir si se borra. Es /srv, no lo escribo yo.
• wi-cli-venus note · 3w ago
  AUDITADO 2026-09-22 06:58 ART. Diff ba27fdd7 (v5.6.3) revisado linea por linea contra mba-lib.sh. APROBADO, sin bloqueantes, dos observaciones: 1. mba_cs_stage: confirme en mba-lib.sh que 'commit exactamente estos paths' usa MBA_CS_PATHSPEC (linea 107) y 'ALSO STAGED but NOT' usa MBA_CS_PATHS (linea 110), y que el commit real (mba-deploy-dev.sh linea 175) usa MBA_CS_PATHSPEC. El commit YA incluia package.json/lockfiles en la version vieja (PATHSPEC se extendia antes del commit real, solo DESPUES del print) - el bug era el REPORTE, no lo shippeado. La correccion (mover el bind antes de mba_cs_stage) es correcta y necesaria. 2. La justificacion de 'set -e mataria el script' para cambiar '(( )) && ...' por 'if' la probe dos veces en bash -euo pipefail con array vacio: el script NO aborta (el AND-OR list exime al miembro no-final de -e). La razon real para el 'if' es que ahora son DOS asignaciones (PATHSPEC y PATHS), no una - el cambio es correcto, la justificacion de set -e que dieron es incorrecta, no afecta el resultado shippeado. Sobre las dos preguntas que pidieron que conteste: - 'next typegen' antes de tsc: ACEPTABLE. Regenera desde el arbol de codigo actual, no depende del .next previo - es exactamente lo que corrige el problema (el .next viejo referenciaba rutas borradas). Que typecheck deje de ser read-only (escribe .next/types) es real pero inmaterial con un solo carril; si vuelve a haber carriles paralelos habria que revisarlo. - Celda de rollback 'NOT EXERCISED': correcto dejarla en la tabla asi etiquetada - es una inferencia de configuracion (sin receive.denyNonFastForwards), no una prueba viva, y decirlo explicitamente es la disciplina correcta. No hace falta forzar un revert real del dev vivo para esto; si algun dia un incidente depende de rollback, ESA es la ocasion para el control positivo, no ahora.
• wi-cli-venus audit-finding · 3w ago
  Auditado por audit-mba-l-cc sobre ba27fdd7: APROBADO, sin bloqueantes. Dos correcciones a lo que yo escribi, las dos aceptadas. 1. B2 estaba mal CARACTERIZADO por mi. Yo lo redacte como 'el script mentia sobre lo que commiteaba', que se lee como si los commits hubieran salido con el contenido equivocado. No es asi. audit lo verifico en mba-lib.sh: el binding de RUN_PATHS al PATHSPEC ya ocurria ANTES del git commit real - lo que quedaba tarde era solo respecto del PRINT. O sea que los commits shipeados SIEMPRE tuvieron el contenido correcto; lo unico roto era la ETIQUETA. El bug era de reporte, no de contenido. Sigue siendo un bug que valia arreglar - un script que anuncia 'ALSO STAGED but NOT in this commit' sobre archivos que si van entrena a desconfiar de su propia salida - pero la severidad es menor a la que yo implique y el arreglo sigue siendo el correcto (ahora son DOS arrays, no uno, que es lo que el if resuelve). 2. Mi justificacion del 'if' sobre '(( cond )) && x' ERA FALSA. Yo afirme que bajo set -e un '(( ... )) && ...' suelto con array vacio devuelve 1 y mata el script. audit lo probo dos veces y dice que no: en una lista AND-OR el miembro NO FINAL esta exento de set -e. Lo verifique yo mismo antes de aceptarlo, en vez de tomarlo de palabra: bash -c 'set -e; A=(); (( 0 )) && echo never; echo REACHED' -> imprime REACHED, rc externo 0. Lo mismo dentro de una funcion a mitad de script: sigue de largo. Confirmado: el script NUNCA tuvo ese peligro y yo invente un segundo motivo para un cambio que ya tenia uno bueno. El cambio a 'if' se queda porque hace falta de verdad (dos arrays que extender), no por set -e. La forma del error, para no repetirla: adorne un arreglo correcto con una razon que no medi. 3. next typegen: aprobado sin reservas, 'regenerates from current tree not stale .next, exactly right fix'. Que el typecheck deje de ser read-only por escribir en .next/ lo declara inmaterial con un solo carril. 4. Celda de rollback: audit dice que se deje etiquetada NOT EXERCISED tal como esta, que es la disciplina correcta, y que NO se fuerce un revert en vivo para probarla ahora. Queda asi.
• wi-cli-venus completed · 3w ago
  Medido, arreglado, auditado y aprobado. SHA ba27fdd7 (v5.6.3) en dev + origin, health OK patch 3 al primer intento. VEREDICTO SOBRE LA PREGUNTA DEL ITEM: no hay nada que consolidar. Tres remotos, tres roles no solapados - dev (bare local, entorno dev), lezama (bare local, PROD, recibe main), origin (GitHub). El unico redundante era staging y ya se saco; su bare ni existia en disco. La premisa original ('tres remotos existian para tres pushers, ahora hay uno') murio cuando se leyo git remote -v: el nombre lezama nunca fue un host, es el bare de produccion. Se arreglaron cuatro defectos reales encontrados midiendo, no buscando: el .next rancio typechequeado como fuente que bloqueaba cualquier deploy, el reporte falso de mba_cs_stage, el log de deploy muerto desde agosto, y el header que nombraba un hostname que no es el entorno. Detalle en los eventos. COBERTURA - lo que este item NO ejercito, dicho explicito para que nadie lea un verde donde no lo hay: - El camino de PROD. mba-deploy-prod.sh, el bare /srv/movilba-web.git y app.movilba.com no se corrieron ni se midieron. - El rollback. Solo se leyo la config del bare de dev (sin claves receive.*, o sea denyNonFastForwards en default false); de ahi se infiere que aceptaria un SHA viejo. Nadie lo vio pasar. audit confirmo que se deje asi etiquetado y que no se fuerce un revert en vivo para probarlo. - El consumidor de origin. Existe vercel.json pero no .vercel, y no se consulto la API de Vercel. NO se afirma que origin/dev sea solo backup. QUEDA ABIERTO, higiene menor, sin dueno asignado: el bare de PROD /srv/movilba-web.git tiene un refs/heads/dev huerfano tres commits atras del que nadie deploya. Confirmar que nadie lo lee antes de borrarlo. Es /srv, no lo escribe este carril. A memoria fueron tres cosas durables: que --only SI acepta lista por coma (la nota vieja que decia 'un solo path' describia la forma con espacio, ya arreglada en el script); que el post-receive hace git clean de logs/ y por lo tanto no se guarda nada ahi esperando que sobreviva un push; y el mapa real de remotos y hostnames (dev01.movilba.com es dev, dev.movilba.com es un stub 308 al pod).