Skip to content
This repository has been archived by the owner on Mar 14, 2024. It is now read-only.

Deploying the site

Jump to bottom
Sam Thorogood edited this page Nov 1, 2021 · 8 revisions

We use Firebase Hosting to host the site as well as Cloud Build to automatically deploy the site.

This page covers how we deploy the site. See Builds for more about how we build the site before deploy.

Cloud Build

The Cloud Build process is broken up into two tasks, version-check and deploy.

version-check

Every hour at five past ('5 * * * *'), version-check runs a node script that compares the current (HEAD of main) commit SHA against the commit SHA of the deployed site. If the two SHAs are different, and there's no build already running, then this task will trigger the deploy task.

⚠️ Technically, the site built is not reproducible as we depend on one source of external data: YouTube playlist data for the pages in /shows/. However, our site changes often enough (the HEAD of main) that this data will quickly show up anyway.

deploy

The deploy task builds a production version of the site to be deployed onto Firebase Hosting as well as updates the Algolia index of the site based on the new production build's content.

  1. The first step installs all dependencies.
  2. Step two runs a script that extracts all the "secrets" from Secret Manager and turns them into a .env file, so that the build commands have all the relevant API keys.
  • The Cloud Build service account has permissions to read the secrets.
  1. The third step is to run a production build of the website.
  2. Next, in step four, the production build of the site is deployed to Firebase using the Firebase community builder image.
  3. Finally, step five, after the site has been deployed, the dist/pages.json (only produced in production builds) is read by algolia.js and then updates the data in Algolia.

Manual Deployment

To manually deploy the site you'll need to be a member of one of these Google teams:

  • web.dev-eng
  • web.dev-owners
  1. Navigate to the Cloud Build Triggers page.
  2. Click the RUN button for the trigger named Deploy.
  3. In the side drawer that opens up, click the RUN TRIGGER button for the trigger for the main branch.

(You could also follow the manual steps above as yourself on a command line.)

NOTE: web.dev auto deploys every hour if there is a new commit in the main branch. Manual deploys should only occur when a build fails or if auto deploys are disabled (you'll have to stop the Cloud Scheduler tasks), because it's likely your build will get clobbered.

Firebase

firebase.json

Firebase requires a firebase.json file in order to configure hosting behavior, this file is not committed to the repo but is instead dynamically generated. The base for this config can be found in firebase.incl.json, any changes you'd want to make should be made there. All of the redirects are maintained in redirects.yaml before being merged into the firebase.json file, so redirects you'd want to add should be added there. (This file mirrors the very old DevSite format.)

When you run npm run build or npm run dev the firebase.json file is generated by the firebase-config.js and then Firebase Hosting for either local development or for a deployment will work.

The redirects are separated from the rest of the config file in order to allow contributors to easily add redirects while firebase-config.js will clean the redirects so that additions will not break the Firebase config.

Google Cloud & Service Accounts

The various tasks above use a small number of (default) Service Accounts on the web-dev-production-1 project.

  • "cloud-build-trigger-scheduler" has permission to kick off the Cloud Build task (version-check), and does so every hour
  • we use the default Cloud Build service account to run all our tasks there
  • the "appspot" service account is used for some legacy tasks (appspot predates Cloud).
Clone this wiki locally