Post-deploy housekeeping: build script order, source maps, ogimage.xcf, old static/ tree

Abierto
  • ¿Algo no está bien?
#488 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 8 días

@stephaniehobson ya está trabajando en esto.

Desde el 9/11/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

Small things noticed while building the deploy pipeline (#480). None is urgent; each is independent, so split this up if that is easier.

  • npm run build orders build:app before build:css. build is npm-run-all build:*, which runs alphabetically, so the Vite build runs before the Stylus compile it depends on. It only works today because both CI and the deploy workflow run npm run build:css as a separate step first. Make build self-sufficient (for example build:1-css, build:2-app, build:3-version.json, or an explicit run-s), then drop the separate step from ci.yml and deploy.yml.
  • Source maps ship to the public bucket. vite.config.mjs sets build.sourcemap: true so npm run size can inspect the bundle, which means roughly 3 MB of .map files are uploaded on every deploy. Decide whether that is wanted. If not, generate maps only for the size command (for example via an env var) and leave the production build without them.
  • public/img/ogimage.xcf is deployed. It is a GIMP source file and gets copied into build/ and uploaded with everything else. Move it out of public/ (or into docs/) so only the rendered PNG ships.
  • Old create-react-app static/ tree in the prod bucket. The May 2025 hand upload left static/js/* and friends in gs://moz-fx-data-static-websit-8565-ensemble. The Vite build uses assets/ instead, so the old tree is dead weight. Once a prod deploy has succeeded and the CDN has moved on, delete static/ from the bucket by hand (never with a root-level rsync --delete; datasets/ shares the bucket). See docs/architecture/deploy.md.

Refs WT-1916.

Lenguaje dominante
JavaScript
Estrellas
21
Forks
7
Merge medio
6 d 6 h
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de mozilla/ensemble

Todos los issues de mozilla/ensemble

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.