Playwright under e2e/, its own npm project so Meteor never sees the dependency
(.meteorignore keeps the directory out of the bundle — a config file at the app
root is otherwise eagerly loaded into the server and crashes it).
Covers what the phase asked for: sign up / log in, creating a zone from the map
and watching the union get painted on /subscriptions and /zones, removing it
again, commenting on a fire, and switching language. The zone spec is the flow
that froze staging on 2026-07-30 — it passes only if the server is still
answering DDP while the union is recomputed.
docker-compose.e2e.yml is a throwaway stack (Mongo on tmpfs, no named volume) so
the destructive seeds cannot be pointed at anything real by accident;
playwright.config.js refuses to start against the staging or production domains.
i18n.spec.js leaves a test.fixme on a real bug found while writing it: the
language chosen in the profile does not survive a page reload.
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.
Primera pasada con secretos: el guard paso en verde y reventó el checkout con
"/var/run/act/workflow/1.sh: line 4: git: not found". La imagen
kaniko-project/executor:debug solo trae busybox y los binarios de kaniko: ni git ni apk
para instalarlo (por eso tampoco valen las actions basadas en Node).
Se baja el tarball del commit por el API de Forgejo (wget + tar de busybox) a ./src y el
contexto de kaniko pasa a apuntar ahi.
Cloudflare ya no esta delante de git.comunes.org, asi que el registry de Forgejo acepta
la capa de 508 MB del bundle (comprobado: subida completa desde groucho, la imagen esta
en comunes/-/packages/container/tcef-web con los tags meteor3 y a24c7a567c).
- compose: `build:` -> `image: git.comunes.org/comunes/tcef-web:${TCEF_WEB_TAG:-meteor3}`.
groucho pasa de 30 min de `meteor build` (que lo dejaron sin ssh) a un pull de segundos.
- workflow: se activa el disparo por push, y se anade una comprobacion de secretos como
primer paso. Sin ella, faltar REGISTRY_TOKEN se descubria a los ~30 min, al intentar
el push; ahora falla en 2 segundos diciendo exactamente que crear y donde.
groucho (5,9 GB, compartidos con Mongo 7 + web + notifications + redis + node-red) se
quedo sin ssh compilando un `meteor build` y hubo que reiniciarlo. El host de despliegue
no debe compilar: debe recibir una imagen.
Workflow para el runner de Forgejo en aaron. Dos decisiones que conviene no deshacer sin
leer fase-9-ci-imagenes.md:
- Kaniko en vez de `docker build`: aaron es host COMPARTIDO (git.comunes.org, Jenkins,
GlitchTip). `docker build` obligaria a montar /var/run/docker.sock en el job (root
equivalente sobre aaron) y ademas el limite de memoria del job no serviria de nada,
porque quien construye es el demonio, fuera del contenedor. Kaniko construye DENTRO
del job: sin socket y con `--memory` que si acota al que come la RAM.
- `--memory=4g --memory-swap=4g`: swap a cero adrede. Preferimos que muera el build a
que aaron pagine y se lleve la forja por delante.
De momento solo `workflow_dispatch`. El disparo por push queda comentado hasta que
git.comunes.org salga de detras de Cloudflare (la capa del bundle son 508 MB contra un
tope de 100 MB del plan gratuito: el push se queda en Retrying eterno) y existan los
secretos REGISTRY_USER/REGISTRY_TOKEN.
