Skip to content

Instantly share code, notes, and snippets.

@jofftiquez
Last active December 16, 2023 08:28
Show Gist options
  • Star 9 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jofftiquez/d0d4e2838f7acea1a92ffaf9a0a84651 to your computer and use it in GitHub Desktop.
Save jofftiquez/d0d4e2838f7acea1a92ffaf9a0a84651 to your computer and use it in GitHub Desktop.
CI/CD - Github Workflow + Firebase Hosting Guide

Template

Below is a template of GitHub's Workflow Action config file. Workflow is GitHub's CI/CD tool, like CircleCI.

Directory relative to the root of your application - .github/workflows/main.yml.

name: Deploy

on: 
  push:
    tags:
      - 'v*'

jobs:
  deploy_to_live:
    name: Deploy prod hosting
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [10]
    steps: 
      - uses: actions/checkout@master
      - uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node }}
      - name: Install Yarn
        run: npm install yarn@latest -g
      - name: Install Firebase Tools
        run: npm install firebase-tools -g
      - name: Install dependencies
        run: yarn
      - name: Run build
        env: 
          SOME_SECRET_KEY: ${{ secrets.SOME_SECRET_KEY }}
        run: yarn build
      - name: Run deploy
        env: 
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
        run: firebase deploy --only hosting:${{ secrets.FIREBASE_HOSTING_ID }} -P ${{ secrets.FIREBASE_PROJECT_ID }}

Breakdown

Let's breakdown the config parts.

This specific workflow action consists of 3 major parts. The name, on (the event trigger), and jobs.

name: Deploy

This is the name of the action. You can add any name you want. For me, I used "Deploy" because that's what this workflow action is all about.

on

The event trigger is responsible on wether a job will be called or not. In this example, you'll notice the block:

on: 
  push:
    tags:
      - 'v*'

This just means that the workflow action will run if a tag that matches the expression 'v*' has been pushed (push) to the repository. So "On push of a tag that matches 'v*'".

E.g. you want to release a new bug fix. You just have to:

  1. Create a version tag: npm version patch (Read about semantic versioning here).
  2. Push the tag: git push --tags

The workflow action will now run.

Another example usage is when anything has been pushed to the master branch:

on: 
  push:
    branches:
      - master

jobs

A workflow run is made up of one or more jobs. Jobs run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the jobs.<job_id>.needs keyword. The .needs propery is it's prerequisite job.

Syntax: jobs.<job_id> - In our example, the job-id is deploy_to_live.

In our deploy_to_live job above you'll also see the following properties:

  • jobs.deploy_to_live.name - The job name, you can put any name you want.
  • jobs.deploy_to_live.runs-on - The operating system you want to use for the job.
  • jobs.deploy_to_live.strategy - The build matrix for your job. On our example, it's node: [10]. You can add multiple node versions on the array.
  • jobs.deploy_to_live.steps - Finally, the steps that will run on your job. This one's pretty self exanatory.

The job will do the step by step process on after the other on the spawned VM. You can do automation here, like testing, building, and/or deployment. You just have to indicate the proper flow of the work to be automated. On our example it goes like:

  1. Install yarn
- name: Install Yarn
  run: npm install yarn@latest -g
  1. Install Firebase Tools - For firebase hosting deployment.
- name: Install Firebase
  run: npm install firebase-tools -g     
  1. Of course, Install dependencies - In our case, using yarn.
- name: Install dependencies
  run: yarn
  1. Build the application
- name: Run build
  env: 
    SOME_SECRET_KEY: ${{ secrets.SOME_SECRET_KEY }}
  run: yarn build

However, in this part, you'll notice that there's an extra step, the env step. This is just the part where we do the environmental variables setup, before actually running the build. This may not be applicable to some cases, but for most of the cases, this part is required.

Workflow will get the value of the secrets.SOME_SECRET_KEY in your repository's setup. To add a new secret variable, just go to your repository > settings > secrets. There, you can add a new key:value pair variable.

  1. And finally, the deployment
- name: Run deploy
  env: 
    FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
  run: firebase deploy --only hosting:${{ secrets.FIREBASE_HOSTING_ID }} -P ${{ secrets.FIREBASE_PROJECT_ID }}

Same with step 4, we are setting up the environmental variables first, then the run the command for deployment.

Disclaimer: This is just a very specific case of using workflow actions, this guide does not cover everything about Github Workflow. For more accurate details, kindly go check out their official documentation.

Please just drop questions on the comment section below. And if you like this guide, kindly give it a star, and consider following me on github for more cool projects or guides like this. Thanks for reading.

@SalmanK81099
Copy link

How do I get the FIREBASE_HOSTING_ID?

@jofftiquez
Copy link
Author

@SalmanK81099 the hosting id is the name of the hosting in your firebase project. Go to Hosting > Add Another Site. Whatever you name this will the hosting id of that deployment.

image

@developerpaaji
Copy link

Thanks

@alexbruno
Copy link

Are deploys with FIREBASE_TOKEN still working?
The latest times I tried, the Firebase-tools log a warning on the command output saying that this option would be deactivated.

@jofftiquez
Copy link
Author

Are deploys with FIREBASE_TOKEN still working? The latest times I tried, the Firebase-tools log a warning on the command output saying that this option would be deactivated.

Haven't tried since, but I think it will be removed soon. Better to use the new auth way

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment