How to deploy Firebase Preview Channels on Travis CI

Firebase has released the long awaited Preview channel functionality, which allows for the testing of updates. All Firebase (not Firestore!) users can benefit from this hosting feature. And you may be asking what about Travis CI or other hosting users? Can they use preview channels as well?

At the time of this article’s publication, GitHub Actions does not yet natively provide automated procedures for Travis CI from GitHub. Below is a solution to use preview channels by Firebase with your existing Travis CI deployment environment.

Check updates with no risk for users' experience

Let’s face the truth, to check the behavior of your polished and tested updates on production, you had to actually push them to production. Then, in case something fails, - get back to a previous version. Application users might have noticed inappropriate system behavior, which is a pity. To get rid of this kind of working situation, we can now use preview channels. Apply this new Firebase feature to automatically deploy updates and see how they behave, with no risk for real users' experience. Also, you can comfortably leave comments for your updates, and amend them with your team. The best thing is that this temporary storage will remove itself after a preview channel link expires. No storage place taken!

Prerequisites:

  • You need to know Travis CI and have experience with the config file.

  • You need to know how to write Bash scripts and know the right stage to run the Bash script for preview channels.

Steps to reproduce:

  1. Create a new local repository.

  2. Create a new GitHub repository.

  3. Run 'git remote add' command to connect your local repository to GitHub repository.

  4. Set up Firebase project.

  5. Set up Travis CI for GitHub repository.

Set up configuration variables - add environment variables in Travis CI. The variables that you need to set up are the two access tokens to work with Firebase and GitHub:

  • To get FIREBASE_TOKEN, use the command: firebase login:ci

If the command doesn’t work, that’s probably because you don’t have firebase-tools installed.

For installation, run the following command: npm i -g firebase-tools, or curl -sL https://firebase.tools | bash

Then - run a firebase login command, then - firebase login:ci. The latter command gives you a Firebase access token that you want to use as a value for this step (To get FIREBASE_TOKEN…​).

Then, apply this value for the GITHUB_TOKEN variable.

  1. In your local repository, run the 'firebase init hosting' command, choose your Firebase project from the list of already existed projects, and configure firebase.json file.

  2. Create .travis.yml file in your local repository.

  3. Create a Bash script - https://devdocs.io/bash/.

  4. Add job to .travis.yml file that should call the script that we’ve created as the step 8.

The job you need to insert into .travis.yml file:

    stages:
     - name: "Deploy to Firebase preview channel"
       if: branch = master AND type = pull_request

    jobs:
    include:
    - stage: "Deploy to Firebase preview channel"
    skip_cleanup: true
    provider: firebase
    project: fir-project-dc47e
    before_script:
    - sudo apt-get install jq
    - npm install firebase-tools -g
    - npm run build:prod
    script: bash deploy-to-firebase-preview-channels.sh

Here fir-project-dc47e - an ID of your Firebase project

  1. Push changes to GitHub and create a pull request.

Now, back to solving our Travis CI issue and enabling its usage with the Preview channel Firebase functionality. Find the solution I came up with in the repository: Travis CI and Firebase preview channels solution.

Or a brief version on gist: .travis.yml: preview channels deployment.

I’ll separate the script into pieces and describe every step below. To deploy successfully, please, follow my guidelines step by step.

I start with a deployment to a preview channel:

#!/usr/bin/env bash
DEPLOY_TO_PREVIEW_CHANNEL_RESULT=$(firebase hosting:channel:deploy pr-$TRAVIS_PULL_REQUEST --expires 30d --token $FIREBASE_TOKEN --json)

After running the deploy command, I get a&nbsp response with an object containing data, and I have the following as a result:

{
    "status": "success",
        "result": {
        "fir-project-dc47e": {
            "site": "fir-project-dc47e",
            "url": "https://fir-project-dc47e--pr-1-t36vykr3.web.app",
            "expireTime": "2021-01-08T09:27:24.847798020Z"
        }
    }
}

Here fir-project-dc47e - an ID of your Firebase project

I add this object to the DEPLOY_TO_PREVIEW_CHANNEL_RESULT variable. This object has a .result parameter containing all the data needed for future operations.

Next, I select data from the .result parameter and add it to a separate variable that corresponds to the parameter name. This variable will contain an object with a key of ngx-bootstrap-demo.

RESULT=`echo ${DEPLOY_TO_PREVIEW_CHANNEL_RESULT} | jq -r '.result'`

For the next step, I extract fir-project-dc47e object from the RESULT variable:

RESULT_DATA=`echo ${RESULT} | jq -r '."fir-project-dc47e"'`

The following goes to RESULT_DATA:

{
    "site": "fir-project-dc47e",
    "url": "https://fir-project-dc47e--pr-1-t36vykr3.web.app",
    "expireTime": "2021-01-08T09:27:24.847798020Z"
}

Now, I extract a website name from the RESULT_DATA variable. The result will go to the SITE variable:

SITE=`echo ${RESULT_DATA} | jq -r '."site"'`

I extract a preview channel URL from RESULT_DATA variable, and the result goes to the URL variable:

URL=`echo ${RESULT_DATA} | jq -r '."url"'`

Then - extracting data with the expiration time from the RESULT_DATA variable. And, I write it down to the EXPIRE_TIME_UTC variable. UTC format is a default one, so I bring it to the needed format which is GMT, in my case.

EXPIRE_TIME_UTC=`echo ${RESULT_DATA} | jq -r .expireTime`
EXPIRE_TIME=$(TZ='GMT' date -d $EXPIRE_TIME_UTC +%c)

The NEW_COMMENT variable creates a text with a project name, link to a preview channel, and its life duration. I’ll add this text of the comment to a pull request later (TRAVIS_PULL_REQUEST/comments).

Then, I extract all the comments from the pull request I want to work on, using the request to GitHub API. The result goes to the COMMENTS variable. The Objects array will have a description for each comment.

COMMENTS=$(curl -H "Authorization: token $GITHUB_TOKEN" -X GET "https://api.github.com/repos/$TRAVIS_REPO_SLUG/issues/$TRAVIS_PULL_REQUEST/comments")

I declare variables for test cycles. Using the SUBSTRING variable, I search for a comment that might have been added before to replace it with the latest one.

COMMENT_ID equals -1 by default. In the future, I’ll assign a comment ID that I find to it. In case of no overlaps appeared, the value stays as default.

SUBSTRING="Project: fir-project-dc47e"
COMMENT_ID=-1

In this cycle, I sort out the COMMENTS array, and extract the body of each comment - its text, and search for a substring in this body. If an overlap is detected, I take the comment ID and assign it to the COMMENT_ID variable. If no overlaps are detected, then nothing is assigned, the loop just runs as before.

for row in $(echo "${COMMENTS}" | jq -r '.[] | @base64'); do
echo ${row}
    _jq() {
        echo ${row} | base64 --decode | jq -r ${1}
    }
    BODY=$(_jq '.body')
    if [[ ${BODY} == *"$SUBSTRING"* ]]; then
        COMMENT_ID=$(_jq '.id')
    fi
done

Finally, I run a COMMENT_ID test, if it equals 0 or is more than 0, it means a&nbsp comment like this exists, and I need to refresh it. Then, I refer to GitHub API (GITHUB_TOKEN). If there’s no comment - the command creates a new comment in a pull request (GitHub API, as well).

if [[ ${COMMENT_ID} -ge 0 ]];
    then
        curl -H "Authorization: token $GITHUB_TOKEN" -X PATCH -d "{\"body\": \"$NEW_COMMENT\"}" "https://api.github.com/repos/${TRAVIS_REPO_SLUG}/issues/comments/${COMMENT_ID}"
    else
        curl -H "Authorization: token $GITHUB_TOKEN" -X POST -d "{\"body\": \"$NEW_COMMENT\"}" "https://api.github.com/repos/${TRAVIS_REPO_SLUG}/issues/${TRAVIS_PULL_REQUEST}/comments"
fi

As a result, I get the link with the comment to a preview channel. And, the comment we get from the previous operation comes from the person which token we use.

60ec1e03db7c7b158aaa61f9 Fo06fCr0FS4nOMpv1cm M5N0MmQuNTKNRJnnUnlegz87jJmLFwrK FRZXA R7ZAk0LfUuAWJpU1tviJ9P8iUy FtGiXlDrp4Qgcq9oW9 u83GMMjgejrpt6rkPTHNNLWlG64wwkH

Any questions?

Feel free to contact me if you have any questions or troubles with deploying the script: [email protected].

More Articles
WorkflowValor Labs Inc.8 The Green, Suite 300 Dover DE 19901© 2024, Valor Software All Rights ReservedPrivacy Policy