Steve
March 12, 2021
Firebase Hosting has an official GitHub action that lets you easily deploy to both production and preview branches with very little work. This is great if you want to get a UI deployed easily and want to have a way to review branches without having to pull them down and run them manually.
But what if you’re using GitLab like us? This blog will cover using the GitLab CI with Firebase Hosting to deploy to production and also previews for any branches. We’ll also make use of Gitlab Environments to automatically add the preview URL to any merge requests on that branch.
If you don’t want to read through the entire blog and just want to see the final configuration, take a look at the example project.
If this is your first time using Firebase in your web application, then to start you need to set up firebase in your project. That link will help you set up a Firebase project & add Firebase Hosting to your app. Simple right?
Next up we’ll authenticate GitLab CI so it can deploy our code.
#1 In your terminal run firebase login:ci
#2 Click the link and log in with your Firebase account
#3 Copy the token that has now appeared in the terminal
#4 Go to your project in GitLab -> Settings -> CI/CD-> Variables
#5 Add a new variable called FIREBASE_TOKEN and paste in the token we copied in step #3
GitLab CI is now authenticated and ready to deploy, so let’s get to the juicy bit.
For our deploy, we’re going to add a stage to our .gitlab-ci.yml file that uses a docker which already contains the Firebase CLI. This means that our stage script can be a single command.
The command to deploy previews is slightly different so we’re going to create a new stage with a slightly different command. We’ll still be using the same docker to keep our script as simple as possible.
Now let’s tell GitLab about our deployments. This’ll give any merge requests on the project a nice “View latest app” button which takes you directly to the deployed preview.
All GitLab requires to set up an environment is a name and a URL. Unfortunately we cannot rely purely on the environment variables available in GitLab as Firebase Hosting previews have randomised strings in their URLs. How do we fix this? Let’s create a small script to grab the URL from Firebase.
The following script:
#1 Checks Firebase Hosting for any existing deploys that are for the current branch and grabs its’ URL
#2 If a deploy doesn’t exist, it creates a new channel (without deploying) and grabs the URL
#3 It then saves the variable to a env file for GitLab CI to pickup
Now we can add a prebuild stage to our .gitlab-ci.yml file. Doing it before the build means that you can use the deploy URL in your build if it requires it.
And finally we update our deploy stage to include a dependency on the prebuild step and tell GitLab about our newly setup environment. If you have a merge request tied to this branch, GitLab will automatically add a “View latest app” button right on the merge request page!
Firebase Hosting previews clean themselves up after a week of no updates by default. But we can proactively clean them up as soon as our branch is merged since they’re probably not very useful after that.
Cleaning up the preview on merge is as simple as adding one more stage to our .gitlab-ci.yml file and then telling our deploy branch stage how to clean up.
Setting up UI projects to deploy production and preview branches to Firebase Hosting is pretty quick and easy, requiring only a small amount of extra code in your project. Thanks to GitLab Environments, these deploys also nicely tie into the merge requests and still have room for expansion depending on your requirements.
You can view the steps from this blog combined into one project in the example project.
If you’re having trouble following along, are curious and want to chat more, or just want to post memes; come and join us on Discord!
I'm a Software Engineer on the nerd.vision team. My skills mostly lie in the UI/Node area, but I also work with the backend services.