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

Aperta
  • Qualcosa non va?
#488 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 8 giorni

@stephaniehobson ci sta già lavorando.

Dal 9/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
JavaScript
Stelle
21
Fork
7
Merge medio
6g 6h
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mozilla/ensemble

Tutte le issue di mozilla/ensemble

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.