Commit graph

2 commits

Author SHA1 Message Date
82d0399c86 fix(maps): el mapa de /fires se quedaba en gris cuando hay clave de Google
All checks were successful
build-image / test (push) Successful in 3m15s
build-image / build (push) Successful in 13m51s
Síntoma: en staging /fires no pintaba teselas ni fuegos, no creaba la
suscripción `activefiresmyloc` y se quedaba con "Actualizando…" para siempre. Se
había atribuido a que el navegador de las pruebas no compone; no era eso. El
mismo navegador pinta la portada, y pinta /fires perfectamente contra un
servidor local.

La diferencia era la clave de Google. `DefMapLayers` montaba el control de capas
con dos capas base (OSM color y gris) y, cuando `Gkeys` resolvía la clave,
volvía a renderizar añadiendo tres capas de Google. En esa segunda pasada
react-leaflet se dejaba por el camino la capa base marcada, y el mapa se quedaba
sin ninguna. En desarrollo no hay clave, así que la segunda pasada no añadía
nada y el bug no se veía nunca.

El control se monta ahora una sola vez, con la lista de capas ya cerrada, y con
un tope de 5 s por si el script de Google no llega: las capas de Google son un
extra, el mapa tiene que salir igual.

Reproducido en local poniendo una clave falsa en settings-ci.json (0 teselas
antes del arreglo, 15 después). Esa clave falsa se queda ahí a propósito, para
que la suite e2e recorra el mismo camino que staging y producción, y
e2e/tests/fires-map.spec.js lo fija: teselas, una única capa base marcada,
suscripción por viewport, y que no se quede en "Actualizando…".

16 tests e2e en verde.
2026-08-01 23:17:50 +02:00
3b04ebceb3 ci(web): run the server suite before building the image
The build job now needs: test, so an image cannot be published with the suite in
red — which is the whole point of this phase. Both jobs live in the same file
because needs: only links jobs within one workflow.

settings-ci.json is committed and contains no secrets: settings-development.json
is gitignored, so CI had nothing to pass to --settings. The one test that cannot
work without a secret is the node-red iron fixture, sealed with the deployment's
own ironPassword; it now reports itself as skipped instead of failing on an hmac
mismatch, and still runs locally against settings-development.json.

Measured locally: 22s and a ~2.0 GB peak for the whole `meteor test` run (its own
mongod included), hence --memory=3g. The meteor-tool download is not cached yet;
the note in the workflow says what that would take.
2026-08-01 18:02:31 +02:00