3 steps for handling GitHub Workflow Secrets
Tags: javascript, github, firebase, secrets
Published: 2021-04-06 23:57:23

---
published: true
title: 3 steps for handling GitHub Workflow Secrets
description: Brief introduction to GitHub Workflow and Secrets
tags: javascript, github, firebase, secrets
cover_image: https://raw.githubusercontent.com/crisarji/blogs-dev.to/master/blog-posts/github-workflow-secrets/assets/steps-1-2-3.png
series:
canonical_url:
---

## What's the matter with Secrets?

Hello developer pal!, glad to see you here.

`Secrets`(aka `environment vars` in other contexts out of GitHub) can be used in different ways, basically they are a `key/value` pairs which allow the interaction with your app, site, blog, etc.

For a `Secret` to work, you will always have visibility for the `Key` but the `Value` will remain hidden till the end of time(or till you update it manually, up to you)!

For this post, in 3 steps we gonna set up a `GitHub Workflow`(_PullRequest_ and _Merge_) for accessing `GitHub Secrets`, and allowing the deploy of a site.

## Show Me The Code

The steps to be focus on are:

1.  Creating the Secrets on GitHub
2.  Connecting the GitHub Secrets to local repo for testing
3.  Connecting the GitHub Secrets to remote repo for GitHub Workflow to kick in

## 1. Creating the Secrets on GitHub

Maybe the "hardest" of the steps; you just need to navigate to the repo where you want to add the data, go to `Settings`, and look for the option `Secrets`

<br/>
<p align="center">
  <img width="90%" src="https://raw.githubusercontent.com/crisarji/blogs-dev.to/master/blog-posts/github-workflow-secrets/assets/repo-new-secret.png">
</p>
<br/>

_Tip_: Though you can add whatever _Name_ and _Value_ you want to, it is better to add a relevant _Name_, since this is the `Key`, something meaningful is crucial.

_Note_: Remember that the _Value_ is hidden right after you save the `Secret` and wont be accessible again!, you can edit but wont see it again, be careful.

For this post purposes, let's take a [Vue](https://vuejs.org/) app + [Firebase](https://firebase.google.com/) project, these `Secrets` would look something like this:

<br/>
<p align="center">
  <img width="90%" src="https://raw.githubusercontent.com/crisarji/blogs-dev.to/master/blog-posts/github-workflow-secrets/assets/repo-secrets-vue-app.png">
</p>
<br/>

## 2. Connecting the GitHub Secrets to local repo for testing

When looking for a consistent project, it is required to be sure that the values of the `Secrets` stored on `GitHub` are working in your app.

Look below that the `Keys` are exactly the same present in the step above, taking [Firebase](https://firebase.google.com/) as an example here since it gives a set of values for identify the required project and it is easy to run and test, but the same logic should apply with keys of any other platform

```js
# ----------------------------------------------------------
# .env file
# ----------------------------------------------------------
VUE_APP_FIREBASE_API_KEY='not-set-yet'
VUE_APP_FIREBASE_APP_ID='not-set-yet'
VUE_APP_FIREBASE_AUTH_DOMAIN='not-set-yet'
VUE_APP_FIREBASE_DATABASE_URL='not-set-yet'
VUE_APP_FIREBASE_MESSAGING_SENDER_ID='not-set-yet'
VUE_APP_FIREBASE_PROJECT_ID='not-set-yet'
VUE_APP_FIREBASE_STORAGE_BUCKET='not-set-yet'
# ----------------------------------------------------------
```

Running this project locally should work for you as expected, if so, you can be sure that the `Secrets` remotely are synced up with the local ones.

_Note_: If you are not familiar with the .env modes, maybe this [reference](https://cli.vuejs.org/guide/mode-and-env.html#environment-variables) could be helpful!

## 3. Connecting the GitHub Secrets to remote repo for GitHub Workflow to kick in

Now you could we wondering, `how can I use those Secrets in my GitHub Workflow?`, well it is quite easy to accomplish using GitHub Action; if you are not familiar with it, maybe you can take a look at this [documentation](https://docs.github.com/en/actions/reference/events-that-trigger-workflows), long story short, you just need to include a `yaml` to a `.github/workflows` folder in your root repo, and add the commands you want to affect the behavior of your app, for instance when pushing a new `Pull Request` or `Merging` to a specific branch.

For this post purposes, an action for a new `Pull Request` is triggered mimicking a Firebase hosted project, keep focus on `env` entry:

```yaml
# This file was auto-generated by the Firebase CLI
# https://github.com/firebase/firebase-tools

name: Deploy to Firebase Hosting on PR
'on': pull_request
jobs:
  build_and_preview:
    env:
      VUE_APP_FIREBASE_API_KEY: ${{ secrets.VUE_APP_FIREBASE_API_KEY }}
      VUE_APP_FIREBASE_AUTH_DOMAIN: ${{ secrets.VUE_APP_FIREBASE_AUTH_DOMAIN }}
      VUE_APP_FIREBASE_DATABASE_URL: ${{ secrets.VUE_APP_FIREBASE_DATABASE_URL }}
      VUE_APP_FIREBASE_PROJECT_ID: ${{ secrets.VUE_APP_FIREBASE_PROJECT_ID }}
      VUE_APP_FIREBASE_STORAGE_BUCKET: ${{ secrets.VUE_APP_FIREBASE_STORAGE_BUCKET }}
      VUE_APP_FIREBASE_MESSAGING_SENDER_ID: ${{ secrets.VUE_APP_FIREBASE_MESSAGING_SENDER_ID }}
      VUE_APP_FIREBASE_APP_ID: ${{ secrets.VUE_APP_FIREBASE_APP_ID }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: npm ci && npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT }}'
          projectId: secret-project-test
        env:
          FIREBASE_CLI_PREVIEWS: hostingchannels
```

As shown above, before running the checkout/deploy steps, the `env` entry takes the wheel; what happens here is that the GitHub Workflow will declare and initialize on its scope the `secrets` already defined in the GitHub repo!, so everything is kept together through 3 different places!:

- The `Secrets` you define on GitHub
- The `Key/Values` you use locally(.env file recommended)
- The `GitHub Workflow` used for the GH Action(`PR`, `Merge`, etc)

A change in the `Secrets` wont mess with the whole logic, editing a value, as long as it is a valid one, will run seamlessly for your devs and users, saving time and avoiding some headaches.

_Note_: you can find more info about the used steps actions here [actions/checkout@v2](https://github.com/actions/checkout) and here [FirebaseExtended/action-hosting-deploy@v0](https://github.com/FirebaseExtended/action-hosting-deploy)

## Conclusion

As shown above, keeping `Secrets`, or `env variables` is not so difficult when following the integration steps; maybe you could have a better way to do it, let's discuss in a thread below!

Thanks for reading!