chore: Run lhci as GitHub action

.github/workflows/lighthouse.yaml → .github/workflows/lighthouse.yml

@@ -1,9 +1,9 @@
 name: Run Lighthouse CI
 on:
-  workflow_run:
-      workflows: ['Build']
-      types: [completed]
-      branches: [main]
+  push:
+    branches: [ main ]
+  pull_request:
+    branches: [ main ]
 jobs:
   lhci:
     name: Lighthouse CI
@@ -17,7 +17,10 @@ jobs:
       - name: npm install
         run: |
           npm install
+      - name: npm run build
+        run: |
+          npm run build
       - name: run Lighthouse CI
         run: |
-          npm install -g @lhci/cli@0.3.x
-          npm run lhci -- --uploadTarget=temporary-public-storage || echo "Running lhci failed"
+          npm install -g @lhci/cli@0.14.x
+          npm run lighthouse -- --upload.target=temporary-public-storage

.github/workflows/unittests.yaml

@@ -29,6 +29,7 @@ jobs:
       - run: npm test -- --coverageThreshold='{"global":{"branches":80,"functions":80,"lines":80,"statements":80}}'
         if: github.event_name == 'schedule'
       - uses: actions/upload-artifact@v4
+        if: always()
         with:
           name: coverage-report
           path: coverage/

config/nimbus.yaml

@@ -98,9 +98,9 @@ features:
       - channel: local
         value: { "enabled": true }
       - channel: staging
-        value: { "enabled": false }
+        value: { "enabled": true }
       - channel: production
-        value: { "enabled": false }
+        value: { "enabled": true }
 enums:
   OptionalBrokerScanInfoFields:
     description: An enum of optional broker scan info fields

docs/dependency-updates.md

@@ -243,7 +243,7 @@ Used to compile cronjob scripts. You can test this by running
 ### `tsx`
 
 Used to run cronjobs locally and compile them on the fly. You can verify this by
-running a cronjob like `npm run dev:cron:monthly-activity`; if the cronjobs run
+running a cronjob like `npm run dev:cron:monthly-activity-plus`; if the cronjobs run
 like in `main`, it's still working.
 
 ### `yaml`

docs/release_process.md

@@ -90,24 +90,30 @@ Once a PR is successfully merged:
 1. ensure that the merge commit in `main` branch passes all checks and a docker image is successfully deployed.
 2. Jenkins will kick off the deployment of the latest built docker image to stage environment
 3. A webhook will send status messages into the `#fx-monitor-engineering` channel.
-   - Watch for messages: `FX MONITOR STAGE STARTED` and `FX MONITOR STAGE COMPLETE`
+   - Watch for messages: `pushing to staging started` and `successfully deployed to staging`
 
 ## Release to Production
 
-Before releasing to production, we need to assess the current state of our work on stage. We need to cross-reference what's already on stage and what's been greenlit by QA. To do this, we need to find the difference between what was released last time in production and what we currently have on stage.
+### Daily pre-releases
 
-### Check the diff in Release Notes and notify the team
+Github pre-releases are generated daily via a (daily-pre-release)[daily-pre-release] GHA workflow.
+The pre-release will include all the PRs that got merged into main (stage) that day.
+The cron job will only execute Monday to Friday.
+As a base load engineer, you can get into a habit of checking pre-releases every morning to see what's been pushed and what's been checked by the QAs. Once everything is checked off in a pre-release, we can proceed to deploying that pre-release to production and mark it as the latest
 
-[make a release on GitHub][github-new-release] in order to check the difference.
+### Deploy to Production
 
-1. Choose the tag you want for your release. Use today's date (e.g., `2024.09.01`)
-2. Type the same tag name for the release title (e.g., `2024.09.01`)
-3. Click the "Generate release notes" button!
-4. _DO NOT_ press "Publish release" yet
-5. Copy and Paste the release notes in the engineering slack channel so the team is aware
-6. Go through the PRs, cross-reference the tickets in the PRs with the [Jira][jira] board to see if QA has approved the tickets. If anything is unclear, make sure to tag the author of the PR.
-7. If anything has not been properly tested, make a note, and again, double check with the person
-8. If everything looks good, proceed to release, otherwise refer to the section `Stage-fixes` below.
+Before deploying to production, we need to assess the current state of our work on stage. We need to cross-reference what's already on stage and what's been greenlit by QA. To do this, we need to find the difference between what was released last time in production and what we currently have on stage.
+
+### Mark pre-release as latest, check the diff in Release Notes, and notify the team
+
+1. Find the pre-release/tag you want to use for the deploy (e.g., `2024.09.01`)
+2. Edit the release
+3. Check the checkbox `Set as the latest release`
+4. Copy and Paste the release notes in the engineering slack channel so the team is aware
+5. Go through the PRs, cross-reference the tickets in the PRs with the [Jira][jira] board to see if QA has approved the tickets. If anything is unclear, make sure to tag the author of the PR.
+6. If anything has not been properly tested, make a note, and again, double check with the person
+7. If everything looks good, proceed to release, otherwise refer to the section `Stage-fixes` below.
 
 ### Update Production Environment Variables
 
@@ -181,8 +187,6 @@ Wherever feature flags aren't applicable, there are generally two scenarios we n
 
 After adding 1-click production deploy capability and broadly adopting [feature flags][feature-flags], we are looking into ways to increase our production release frequency. The main challenge here is to coordiate our QA effort with our latest stage CICD deployments.
 
-We are starting to look into creating daily GitHub pre-releases via GHA, and once QA'd, having these deployed automatically or manually by base load engineers.
-
 [prod]: https://monitor.firefox.com/
 [stage]: https://stage.firefoxmonitor.nonprod.cloudops.mozgcp.net/
 [readme]: https://github.com/mozilla/blurts-server/blob/main/README.md
@@ -195,3 +199,4 @@ We are starting to look into creating daily GitHub pre-releases via GHA, and onc
 [jira]: https://mozilla-hub.atlassian.net/jira/software/c/projects/MNTOR/boards/447
 [dockerhub]: https://hub.docker.com/r/mozilla/blurts-server/tags
 [1-click deploy]: https://github.com/mozilla/blurts-server/actions/workflows/production_deploy.yml
+[daily-pre-release]: https://github.com/mozilla/blurts-server/actions/workflows/release_cron_daily.yml

lighthouserc.cjs

@@ -9,29 +9,16 @@ const pages = [
   "/how-it-works",
 ];
 
-const getArgVariable = (argKey) => {
-  const argKeyIndex = process.argv.findIndex((arg) => arg === argKey);
-  if (argKeyIndex >= 0 && argKeyIndex < process.argv.length) {
-    const argValue = process.argv[argKeyIndex + 1];
-    if (!(argValue && argValue.startsWith("--"))) {
-      return process.argv[argKeyIndex + 1];
-    }
-  }
-
-  console.info(`No value provided for arg ${argKey}`);
-};
 const collectBaseUrl =
-  getArgVariable("--collectUrl") ?? "http://localhost:3000";
-const target = getArgVariable("--uploadTarget") ?? "filesystem";
-
+  process.env.LIGHTHOUSE_COLLECT_URL ?? "http://localhost:3000";
 const lighthouseConfig = {
   ci: {
     collect: {
       startServerCommand: "npm run start",
       url: pages.map((pathname) => `${collectBaseUrl}${pathname}`),
     },
     upload: {
-      target,
+      target: "filesystem",
       outputDir: ".lighthouseci",
     },
   },

locales/el/app.ftl

@@ -250,7 +250,7 @@ error-page-error-other-title = { $errorCode }: Κάτι πήγε στραβά
 
 ## Breach overview page
 
-all-breaches-headline-3 = Βάση δεδομένων παραβίασης δεδομένων
+all-breaches-headline-3 = Βάση δεδομένων παραβιάσεων
 all-breaches-lead = Παρακολουθούμε όλες τις γνωστές παραβιάσεις δεδομένων για να διαπιστώσουμε εάν τα προσωπικά σας στοιχεία παραβιάστηκαν. Ακολουθεί μια πλήρης λίστα με όλες τις παραβιάσεις που έχουν αναφερθεί από το 2007.
 search-breaches = Αναζήτηση παραβιάσεων
 # the kind of user data exposed to hackers in data breach.

locales/el/breaches.ftl

@@ -2,7 +2,7 @@
 # License, v. 2.0. If a copy of the MPL was not distributed with this
 # file, You can obtain one at http://mozilla.org/MPL/2.0/.
 
-breach-all-meta-page-title = Βάση δεδομένων παραβίασης δεδομένων — { -brand-fx-monitor }
+breach-all-meta-page-title = Βάση δεδομένων παραβιάσεων — { -brand-fx-monitor }
 breach-all-meta-social-title = Όλες οι παραβιάσεις που εντοπίστηκαν από το { -brand-fx-monitor }
 breach-all-meta-social-description = Περιηγηθείτε στην πλήρη λίστα των γνωστών παραβιάσεων που εντοπίστηκαν από το { -brand-fx-monitor } και μάθετε εάν αποκαλύφθηκαν οι πληροφορίες σας.
 # Variables:

locales/es-ES/app.ftl

@@ -211,7 +211,7 @@ error-page-error-other-title = { $errorCode } Se ha producido un error
 
 ## Breach overview page
 
-all-breaches-headline-2 = Todas las filtraciones detectadas por { -brand-fx-monitor }
+all-breaches-headline-3 = Base de datos de filtraciones de datos
 all-breaches-lead = Supervisamos todas las filtraciones de datos conocidas para averiguar si tu información personal se vio comprometida. Aquí hay una lista completa de todas las filtraciones que se han notificado desde 2007.
 search-breaches = Buscar filtraciones
 # the kind of user data exposed to hackers in data breach.

locales/es-ES/breaches.ftl

@@ -2,21 +2,17 @@
 # License, v. 2.0. If a copy of the MPL was not distributed with this
 # file, You can obtain one at http://mozilla.org/MPL/2.0/.
 
-breach-all-meta-title = { -brand-fx-monitor } - Todas las filtraciones de datos
+breach-all-meta-page-title = Base de datos de filtraciones de datos — { -brand-fx-monitor }
 breach-all-meta-social-title = Todas las filtraciones detectadas por { -brand-fx-monitor }
 breach-all-meta-social-description = Explora la lista completa de filtraciones conocidas detectadas por { -brand-fx-monitor }, luego averigua si tu información estuvo expuesta.
-
+# Variables:
+#   $company (String) - Name of the company that was breached, e.g. "PHP Freaks"
+breach-detail-meta-page-title = Filtración de datos de { $company } – { -brand-fx-monitor }
 # Variables:
 #   $company (String) - Name of the company that was breached, e.g. "PHP Freaks"
 breach-detail-meta-social-title = ¿Te afectó la filtración de datos de { $company }?
 breach-detail-meta-social-description = Usa { -brand-fx-monitor } para averiguar si tu información personal fue expuesta en esta filtración y saber qué hacer a continuación.
 
-## Breaches header
-
-## Breaches resolved filter
-
-## Breaches table
-
 ## Links that we might refer to when prompting the user to make changes after a breach
 
 breach-checklist-link-firefox-relay = { -brand-relay }
@@ -26,7 +22,6 @@ breach-checklist-link-mozilla-vpn = { -brand-mozilla-vpn }
 ## Prompts the user for changes when there is a breach detected of password
 
 breach-checklist-pw-header-text = Actualiza tus contraseñas y activa la autenticación de dos factores (2FA).
-
 # The `breached-company-link` tags will be replaced with link tags or stripped if no link is available.
 # Variables:
 #   $passwordManagerLink (string) - a link to the password manager documentation, with { -breach-checklist-link-password-manager } as the label
@@ -95,7 +90,6 @@ breach-checklist-phone-header-2 = Protege tu número de teléfono con un servici
 ## Prompts the user for changes when there is a breach detected of security questions
 
 breach-checklist-sq-header-text = Actualiza tus preguntas de seguridad.
-
 # The `breached-company-link` tags will be replaced with link tags or stripped if no link is available.
 breach-checklist-sq-body-text = En la mayoría de los casos, te recomendamos que actualices tus preguntas de seguridad en el sitio web de la empresa. Pero <b>su sitio web puede estar inactivo o contener contenido malicioso</b>, así que ten cuidado si <breached-company-link>visitas el sitio</breached-company-link>. Para mayor protección, actualiza estas preguntas de seguridad en cualquier cuenta importante donde las hayas usado, y crea contraseñas únicas y diferenciadas para cada cuenta.