Github Actions Environment Variables: Guide, Examples & Tips

With more than 70 million active users, Github is the online studio of many software developers. Github Actions, one of the Github platform’s many features, makes it easy to host software workflows running on any Github event to automate daily developer tasks. With Github Actions environment variables, you can even customize these workflows to suit your own business logic.

But what about API keys and credentials used as Github Actions env variables? At Onboardbase, we make it easy to manage app secrets collaboratively while using Github Actions. In the following article, we tell you how to get started with Github Actions variables, and how to best deal with them to avoid security breaches.

What Are Github Actions Environment Variables

Github Actions environment variables allow you to store information―API keys, login credentials, app secrets, constants, etc―to use in your Github Actions jobs.

For example, given the following workflow configuration that prints the value of the environment variable ENV_VARIABLE on each git push of the corresponding code repository:

test.yml

name: Github Actions test
on: [push]
env: 
	ENV_VARIABLE: ok
jobs:
	test:
		runs-on: ubuntu-latest
		steps:
			- run: echo "$ENV_VARIABLE"

The job will print the word “ok”:

Why Are Github Actions Env Variables Important?

Github Actions allows developers to set up Continuous Integration / Continuous Delivery (CI/CD) pipelines directly from within git repositories, making it easy to build, test, and deploy code to development, staging, and production environments alike with the use of appropriate environment variables. Say you have a React app as a website, you would be able to use Github Actions to run npm build on each git push and have your web server download your latest production bundle automatically like Netlify or Vercel do natively.

Github Actions jobs can also be configured to orchestrate third-party services using their respective API keys as env variables to automate workflows like Zapier, Integromat, or IFTTT does―only with more customization possibilities. You can for example have a job that sends a message to your dev workspace on Slack on each new Github discussion, making it easier to ask and answer questions posted on Github.

Last but not least, Github Actions offers a generous free plan of 2000 CI/CD minutes per month for all your private repositories. It will not only increase the quality of your operations, but also save you time and money by not having to maintain a server yourself.

How To Use & Manage Github Actions Secrets In 7 Steps

1. Create a new Github Personal Access Token

You’ll need a Github personal access token (PAT) to access Github’s API from the command line and update Github Actions workflows.

Go to your Github account and click on Settings > Developer Settings > Personal Access Tokens. Press the button “Generate new token”. Just make sure to check Workflow in the list of scopes and you’re good to go.

Quick tip: instead of having your dev tokens scattered around different services, you can use Onboardbase to store your secrets in a central repository for all the developers in your team to access from a beautiful user interface:

2. Create a new Github repository

We are going to create a new repository to host your Github Actions workflow. Create a new folder and initialize git:

git init

In Github, create a new private Github repository and go back to the command line with the URL of your new repository:

git branch -M main
git remote add origin https://github.com/<your account>/t.git

3. Create a Github Actions workflow file

A Github Actions workflow is simply a configuration file written in YAML where you can call scripts using the Bash programming language. Let’s write a simple one that will display text in the command line interface:

name: Github Actions test
on: [push]
jobs: 
	test:
		runs-on: ubuntu-latest
		steps:
			- run: echo "test"

The workflow configuration needs a name, a list of Github events triggering the workflow, and a step-by-step description of the jobs it contains.

In this example, our workflow is named Github Actions test, runs on each git push, and contains a single job called test that uses a virtual machine running the operating system Ubuntu and outputs the word test.

It’s interesting to note Github proposes 35 events you can use workflows with, most notably:

page_build - when a Github Page is updated
project_card - when a card is added or modified in a project board
discussion - when a discussion is added or modified
issues - when an issue is added or modified
push, pull_request, & fork - when a change is pushed or pulled to/from a repository, when a repository is forked.

4. Set environment variables

Github Actions already offers default environment variables that can come in handy out of the box. Some interesting ones:

GITHUB_ACTION_PATH - to access files located in the same repository as the action
GITHUB_EVENT_NAME - to get the name of the event that triggered the action
GITHUB_REPOSITORY - the repository the workflow belongs to
GITHUB_SHA - to obtain the id of the commit that triggered the workflow

But things get more interesting when you set your own environment variables. The syntax for a user-defined Github Actions environment variable is as simple as:

name: Github Actions test
on: [push]
env: 
	ENV_VARIABLE: test
jobs:
	test:
		runs-on: ubuntu-latest
		steps:
			- run: echo "$ENV_VARIABLE"

This environment variable is global, but Github Actions env variables can be scoped to single jobs:

name: Github Actions test
on: [push]
jobs:
	test:
		runs-on: ubuntu-latest
		env: 
			ENV_VARIABLE: test
		steps:
			- run: echo "$ENV_VARIABLE"

5. Commit & push the changes

Your workflow is now ready to use. Push your code online to have Github Actions’ servers run your custom job:

git add *
git commit -m "first commit"
git push -u origin main

6. Monitor your job’s execution

Github offers a graphical interface to monitor your job’s execution and see if your configuration works as expected. You can find it in your Github account under the Actions tab:

As expected, the command line displays the value of the environment variable, “test”.

7. Secure your Github Actions environment variables secrets

The previous steps showed a simple example to use environment variables, but storing app secrets to login third-party services is one of the most frequent use cases for environment variables.

App secrets, API keys, and credentials are sensitive information―you don’t want to hardcode them in your configuration file and risk a security breach, so you need a way to inject them in environment variables at run time. Two options for this:

Option 1: Onboardbase

Onboardbase is a collaborative platform for developers to manage app secrets that can be used with Github Actions with little configuration:

Create a new project

Here we created a single environment variable called “SECRET_ENV_VARIABLE” with the value “thisisthesecret”.

Create a new service token for Onboardbase

Go to Settings > Manage your org > Service Token and generate a new service token to authenticate with Onboardbase from Github Actions.

Add your Onboardbase token to Github Secrets

Go to your Github repository, click on Settings > Security > Secrets > Actions, and add your Onboardbase token:

Github Secrets are encrypted variables you can reference in Github Actions workflows using the secrets variable, as you will see in the next step.

Update your workflow configuration file

We add 3 steps to the workflow to inject variables at run time:

name: Github Actions test
on: [push]
jobs:
	test:
		runs-on: ubuntu-latest
		env:
			ENV_VARIABLE: test
		steps:
			- name: Download Onboardbase
				run: wget https://onboardbase-cli.fra1.digitaloceanspaces.com/apt/onboardbase.deb
			- name: Install Onboardbase
				run: sudo dpkg -i ./onboardbase.deb
			- name: Setup Onboardbase
				run: onboardbase config:set --token "${{ secrets.ONBOARDBASE_TOKEN }}"
			- name: Inject env variable
				run: onboardbase build -c "printenv SECRET_ENV_VARIABLE" -e "development"

The first step downloads onboardbase’s debian package to your Github Actions server and the second step installs it. It only takes a few seconds.

The third step uses the token stored in Github Secrets to set up an onboardbase config file containing all your app secrets. It’s the only credential you’ll need.

The last step uses Onboardbase’s CLI features to inject new Github Actions env variables. The first line creates a new environment variable called SECRET_ENV_VARIABLE from the value stored in your Onboardbase account, while the second line prints its content.

As expected, the program prints the value of SECRET_ENV_VARIABLE correctly, “thisisthesecret”:

Option 2: Github Secrets

As we just mentioned, Github also allows developers to refer to credentials stored in Github Secrets using the secrets variable, so why don’t we just use that? While it may look easier at first, Github Secrets presents several inconvenients over Onboardbase:

Difficult collaboration - Onboardbase proposes an intuitive, simple user interface that makes it easy to share secrets with your team without getting deployment environments mixed together.
Difficult to maintain - Onboardbase gives you a single central location where you can update all of your secrets, which is much easier than hopping from one app to another when you need to change a value.
Vendor lock-in - Github Secrets can only be accessed from Github. Onboardbase makes it easy to use app secrets everywhere, no matter your tech stack from frontend frameworks like React to backend with Laravel or CI/CD pipelines like Gitlab CI/CD.

Use Onboardbase To Manage Your Github Actions Environment Variables

In this article, you’ve learned how to use Github Actions env variables, why they are useful, and how to securely store them.

Using sensitive Github Action environment variables doesn’t have to be risky: try Onboardbase for free now and forget worrying about your app secrets being leaked. It only takes a minute to get started and share env vars with your whole team.