Releases y compatibilidad¶
Responde: ¿qué versión exacta compone el sistema, y cómo se la vuelve a levantar?
Hasta el 2026-10-14 esta página decía «pendiente», y el motivo era real: ninguno de los cinco repositorios tenía tags, así que no había forma de nombrar una versión entregada. La matriz de evidencias lo registraba como uno de los dos eslabones rotos de la trazabilidad. Este es el que se cierra acá.
v1.0.0-rc1 — candidata de entrega¶
Qué significa candidata
No es la entrega final: es el punto fijo sobre el que se ejecutan las pruebas integrales.
Cualquier corrección posterior produce rc2. Lo que no cambia es el principio: ninguna
prueba vale si no dice sobre qué versión corrió.
La propiedad que la hace creíble¶
No se construyó: se fotografió. Los commits etiquetados son exactamente los que estaban desplegados en producción al fijarla, verificado contra las dos plataformas:
| Plataforma | Lo que declara | Commit |
|---|---|---|
| Cloud Run | La imagen servida está etiquetada con el SHA del commit | c70846927c89944e02b4d53e57364943cdc62259 |
| Vercel | El despliegue productivo declara githubCommitSha |
6aecbfc305ebaf57fc42cdcde5eb1c14a6d3c315 |
No hay distancia entre «lo que se entrega» y «lo que está corriendo».
Los componentes¶
| Repositorio | Tag | Commit | Fecha | Rama |
|---|---|---|---|---|
embolsadora4.0-cloud |
v1.0.0-rc1 |
c708469 |
2026-10-07 | main |
embolsadora-frontend |
v1.0.0-rc1 |
6aecbfc |
2026-10-07 | main |
embolsadora-edge |
v1.0.0-rc1 |
03eb3cb |
2026-10-07 | main |
embolsadora-docs |
v1.0.0-rc1 |
72c0d90 |
2026-10-10 | main |
embolsadora-bundle |
v1.0.0-rc1 |
3362ef0 |
2026-10-14 | main |
historian (proyecto-embolsadora) |
— | ebe79b8 |
2026-04-19 | main, repositorio de terceros |
En los cuatro repositorios etiquetados, main y develop tienen contenido idéntico al
momento de la foto: no hay trabajo mergeado en una rama y ausente en la otra.
Artefactos desplegados¶
| Imagen del Cloud | us-east1-docker.pkg.dev/embolsadora/cloud-run-source-deploy/embolsadora-api |
| Digest | sha256:a2a45ddfc1a91a59ec59f62daf3d9960254f4554b64e897dd7733cc20adfd5cf |
| Revisión de Cloud Run | embolsadora-api-00028-5jk, con tráfico desde 2026-10-08 |
| URL del backend | https://embolsadora-api-dsv2vko7lq-ue.a.run.app |
| Despliegue del frontend | dpl_6Px2uJYLJB7eThucK8kqjTFy137S (Vercel, producción, 2026-10-07) |
El digest es lo que hace la imagen inmutable: un tag puede reescribirse, un digest no.
Estado del CI en los commits etiquetados¶
| Repositorio | Workflows | Resultado |
|---|---|---|
| Cloud | CI, Deploy to Cloud Run, Docs |
éxito |
| Frontend | CI/CD Pipeline, Harness documental |
éxito |
| Edge | ci, harness |
éxito |
| Docs | Documentación, Frescura de la documentación |
éxito |
Con la salvedad que documenta calidad y resiliencia: verde no quiere decir verificado. En el Cloud los tests de integración se saltean por no proveer bases, y en el frontend los E2E corren después del despliegue, no antes.
Lo que queda fuera, y por qué¶
embolsadora-bundle¶
El repositorio tenía el PR #1, «Stack unificado para Raspberry Pi (historian + InfluxDB + edge)», abierto desde el 2026-09-22 y sin mergear. Se mergeó el 2026-10-14 para fijar la rc1, porque es el armado que hace ejecutable la prueba integral transversal: sin él, levantar historian + InfluxDB + Edge es trabajo manual cada vez.
Aporta los dos docker-compose, el runbook de docs/pi.md y scripts/smoke.sh. Su
.env.example no tiene valores reales y el compose declara las variables como requeridas con
${VAR:?}, así que la ausencia de configuración falla de entrada en lugar de arrancar a medias.
Es el único de los cinco repositorios sin workflows de CI: nada verifica automáticamente que el stack levante. Esa verificación la va a dar su uso en las pruebas integrales, no el repositorio.
El historian¶
Vive en un repositorio de terceros (TECPRO): no se puede etiquetar desde este proyecto, así que se fija por commit. Es el componente con la mejor verificación del sistema —su CI levanta una InfluxDB real y comprueba por consulta que los puntos llegaron— y a la vez el único cuyo versionado no está bajo control del equipo. Conviene pedirles un tag.
Configuración¶
Los tres repositorios con configuración tienen .env.example y ninguno contiene secretos
reales: usan marcadores (<user>, <pass>, <anon-key>, dev-key-change-me). Verificado
sobre los commits etiquetados. El procedimiento está en
configuración y secretos.
Hay secretos fuera de los repositorios
El saneamiento de credenciales expuestas en documentos compartidos es trabajo pendiente y
anterior a cualquier entrega. Esta página sólo afirma que los .env.example de los
repositorios etiquetados están limpios.
Cómo se reproduce¶
El procedimiento vive en instalación en planta y
despliegues. Lo que esta página agrega es sobre qué versión
aplicarlos: git checkout v1.0.0-rc1 en cada repositorio.
El procedimiento está escrito y no está verificado
Nadie levantó el sistema desde cero siguiendo únicamente esta documentación. Hasta que eso ocurra, «reproducible» es una intención y no un hecho.
El criterio es deliberadamente severo: lo prueba quien no lo escribió, y si hace falta preguntar algo que no está en la página, la página se corrige. Es el paso que convierte esta release en una entrega.
Relacionado¶
- Matriz de evidencias — el eslabón release que esta página cierra
- Despliegues · Instalación en planta
- Calidad y resiliencia