Automatically deploy to Firebase with Gitlab CI

Since Firebase CLI tools are installed as a Node.js/NPM package it is actually pretty straightforward to setup automatic deployment with continuous integration. This article will focus on clarifying the use of Firebase CLI and setting up Gitlab CI.

This article will walk you through how to setup your project so that it automatically builds (possibly also run tests) and if all looks good, gets deployed to Firebase. Only by pushing our code to upstream repository.

If your repository is hosted on Github or Bitbucket, you can also automatically deploy your Firebase project by integrating with Travis CI or any similar service. But this article will focus on Gitlab, because I think that the built in feature for CI workers is a natural a smart thing to offer as part of the service, as much as issue tracker is.

And if you are developing for GCP or generally interested in knowing more about how powerful continuous integration is, then please read my article covering automatic deployment to Google App Engine, which includes installing debian packages during the build process.

First of all, you need to have a Firebase project setup. I am going to assume that you are having some, or a lot of experience of working with Firebase if you are reading this article. Otherwise, the official documentation is pretty thorough on how you go about to get started with firebase.

Firebase CLI tools

The starting point for this section is that you have your project is setup and you have installed Firebase tools. The next step is to obtain an access token to your Firebase project. Because as you normally sign in with firebase-tools on the command line, you have the option to interactively login. But with continuous integration you’ll need to have a pre-approved access token to provide.

% firebase login:ci
Visit this URL on any device to log in:
https://accounts.google.com/o/oauth2/auth?client_id=123456789-fgrhgmd42bananaj5i8b5prd3ho449e6.a
.com&scope=email%20openid%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloudplatformprojects.readonl
.googleapis.com%2Fauth%2Ffirebase&response_type=code&state=5475783&redirect_uri=http%3A%2F%2Flocal
Waiting for authentication…
+ Success! Use this token to login on a CI server:
1/qX11M4Y400rn4Ezlj-q9LhtLrI13S4R400_J1y1BdQXDiE4NTvo
Example: firebase deploy — token “$FIREBASE_TOKEN”

By using the command option “login:ci” we’ll be presented walked through an OAuth sign-in sequence. You’ll be presented with an URL that you can copy paste to your browser, but most likely the firebase-tools have already opened the URL in your browser.

Take a note of the OAuth token that you got (i.e. “1/qX11M4Y400rn4Ezlj-q9LhtLrI13S4R400_J1y1BdQXDiE4NTvo” in the example above). You will need it for your Gitlab setup below.

Gitlab CI setup

The starting point of this section is that your Firebase project is already setup with a repository on Gitlab. The next step is to configure your environment variables for the project. You will need to set the OAuth token that will be used in your automatic deployment to Firebase.

Gitlab environment variable settings

As hinted in the output from the firebase-tools above, you’ll use that in your continuous integration configuration script as below. You can actually go ahead and just copy/paste this gist into your “.gitlab-ci.yml” file. But you’ll need to continue reading below the gist to get the project setup to match.

Breakdown

First of all, edit the npm install process to match your own project setup. I’ve left the bower installation in just to highlight a certain characteristic of the docker instance.

All the commands are run as root, make sure that the program you run does not have issues with that
- bower install --allow-root

When installing bower packages you must explicitly specify the “allow root” switch.

- firebase use --token $FIREBASE_DEPLOY_KEY production

The “$FIREBASE_DEPLOY_KEY” will be replaced with the auth key that was configured in Gitlab environment variables, but it will never be outlined or exposed in the command output log.

The last part of the line that says “production” is important to pay attention to. Because it is referring to the project alias in the project’s “.firebaserc” configuration file. This can also be set with the firebase-tools command:

% firebase use --add <project id> production

Where you just replace the <project id> with your production project id.

- firebase deploy -m "Pipeline $CI_PIPELINE_ID, build $CI_BUILD_ID" --non-interactive --token $FIREBASE_DEPLOY_KEY

Finally during the Firebase deploy process we’re switching off the interactive deployment process in the console, since the build script will not be able to answer any yes/no questions. This will simply make the script fallback into default answers, which is most of the time ok.

Secondly, I’ve found it handy to provide some information to the Firebase app instance. In the “-m” switch I am providing the pipeline ID and the build ID so that it is simple to jump over to the Gitlab CI pipelines and builds to track down the status or log of the build that deployed a certain Firebase app version.

If you open the “hosting section of your Firebase project, you’ll see a list of your application versions and with the information above, it will look like this

Now it’s quick and simple to jump directly over to the Gitlab list of pipelines to find #4028369.

And clicking it will open the overview of build jobs that were performed in the pipeline.

Build pipeline

That’s all folks. Happy automation!