Introduction
In GitHub Actions, variables store reusable, nonsensitive information like usernames, paths, or configurations. A variable can be scoped to a single workflow or across multiple workflows so that it is easy to maintain settings that might be different across various environments. Outside of this, GitHub has set a few default environment variables that we can use in various of our actions, or could define our own custom ones. And we can also fetch the values of these variables anywhere inside our workflow using contexts.
Why is it useful?
That way, this will simplify the configurations within our workflows. We are not going to hard-code values but instead declare some variables and then reuse their values throughout the steps or jobs in order for the workflows to be more maintainable or debuggable. After that, we could then have more flexibility regarding maintenance for various environments, whereby this would reduce the possibilities of errors from manual entries.
Using ENV variables
Custom Variables
You may declare environment variables at a scope of workflow, job, or step. Here's how:
// ".github/workflows/env-variables.yml" name: Greeting on variable day on: workflow_dispatch env: DAY_OF_WEEK: Monday # Workflow level variable jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello # Job level variable steps: - name: "Say Hello Mona it's Monday" run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona # Step level variable Accessing Variables
The Variables can be accessed using Environment variables or using contexts in other parts of the workflow. It is possible for example to access as:
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" If you want to access them via contexts instead of directly as environment variables, use the following:
run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!" Security Concerns
Variables aren't masked in output so for passwords or API keys you should utilize GitHub Secrets. As an example, to access secrets you would normally do something like:
steps: - name: Use secret run: echo "Your secret is ${{ secrets.MY_SECRET }}" Configuration Variables
These can be reused in multiple workflows using the organization, repository, or environment levels. They are referenced using the vars context.
on: workflow_dispatch env: env_var: ${{ vars.ENV_CONTEXT_VAR }} # Access configuration variables jobs: display-variables: runs-on: ${{ vars.RUNNER }} steps: - name: Show variables run: | echo "Repo variable: $REPOSITORY_VAR" echo "Org variable: $ORGANIZATION_VAR" echo "Overridden variable: $OVERRIDE_VAR" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} Passing Data Between Jobs
If there is a need to pass values across jobs or steps, then that's where you'll be using the job outputs. Here's how:
jobs: job1: runs-on: ubuntu-latest steps: - name: Generate value id: step1 run: echo "::set-output name=my_var::Hello World" job2: needs: job1 runs-on: ubuntu-latest steps: - name: Use value from job1 run: echo "The value is ${{ steps.step1.outputs.my_var }}" Setting ENV variables
Creates or updates an environment variable for any actions running next in a job. The action that creates or updates the environment variable can't access the new value, but all subsequent actions in a job will have access. Environment variable names are case-sensitive and you can use punctuation.
- name: Set env run: echo "GITHUB_SHA_SHORT=$(echo $GITHUB_SHA | cut -c 1-6)" >> $GITHUB_ENV - name: Test run: echo $GITHUB_SHA_SHORT Conclusion
Environmental and configuration variables, on the other hand, reduce the overhead of managing workflows and decrease the complexity of GitHub Actions. Whether you have to use variables across multiple workflows or protect sensitive information stored in secrets, variables are flexible and reusable solutions that will minimize errors and improve maintainability.
Top comments (0)