Variables

About variables

You can use variables to store information that you want to reference in your workflow. You reference variables within a workflow step or an action, and the variables are interpolated on the runner machine that runs your workflow. Commands that run in actions or workflow steps can create, read, and modify variables.

You can set your own custom variables, you can use the default variables that GitHub sets automatically, and you can also use any other variables that are set in the working environment on the runner. Variables are case-sensitive.

Defining environment variables

To set a custom environment variable, you can define it using the env key in the workflow file. The scope of a custom variable set by this method is limited to the element in which it is defined. You can define variables that are scoped for:

• The entire workflow, by using env at the top level of the workflow file.
• The contents of a job within a workflow, by using jobs.<job_id>.env.
• A specific step within a job, by using jobs.<job_id>.steps[*].env.

name: Greeting on variable day

on:
  workflow_dispatch

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

name: Greeting on variable day

on:
  workflow_dispatch

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

You can access env variable values using runner environment variables or using contexts. The example above shows three custom variables being used as environment variables in an echo command: $DAY_OF_WEEK, $Greeting, and $First_Name. The values for these variables are set, and scoped, at the workflow, job, and step level respectively. For more information on accessing variable values using contexts, see "Using contexts to access variable values."

Because runner environment variable interpolation is done after a workflow job is sent to a runner machine, you must use the appropriate syntax for the shell that's used on the runner. In this example, the workflow specifies ubuntu-latest. By default, Linux runners use the bash shell, so you must use the syntax $NAME. If the workflow specified a Windows runner, you would use the syntax for PowerShell, $env:NAME. For more information about shells, see "Workflow syntax for GitHub Actions."

Naming conventions for environment variables

When you set an environment variable, you cannot use any of the default environment variable names. For a complete list of default environment variables, see "Default environment variables" below. If you attempt to override the value of one of these default variables, the assignment is ignored.

Any new variables you set that point to a location on the filesystem should have a _PATH suffix. The GITHUB_ENV and GITHUB_WORKSPACE default variables are exceptions to this convention.

Using contexts to access variable values

Contexts are a way to access information about workflow runs, variables, runner environments, jobs, and steps. For more information, see "Contexts". There are many other contexts that you can use for a variety of purposes in your workflows. For details of where you can use specific contexts within a workflow, see "Contexts."

You can access environment variable values using the env context.

Using the env context to access environment variable values

In addition to runner environment variables, GitHub Actions allows you to set and read env key values using contexts. Environment variables and contexts are intended for use at different points in the workflow.

Runner environment variables are always interpolated on the runner machine. However, parts of a workflow are processed by GitHub Actions and are not sent to the runner. You cannot use environment variables in these parts of a workflow file. Instead, you can use contexts. For example, an if conditional, which determines whether a job or step is sent to the runner, is always processed by GitHub Actions. You can use a context in an if conditional statement to access the value of an variable.

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        if: ${{ env.DAY_OF_WEEK == 'Monday' }}
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

env:
  DAY_OF_WEEK: Monday

jobs:
  greeting_job:
    runs-on: ubuntu-latest
    env:
      Greeting: Hello
    steps:
      - name: "Say Hello Mona it's Monday"
        if: ${{ env.DAY_OF_WEEK == 'Monday' }}
        run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
        env:
          First_Name: Mona

In this modification of the earlier example, we've introduced an if conditional. The workflow step is now only run if DAY_OF_WEEK is set to "Monday". We access this value from the if conditional statement by using the env context.

You will commonly use either the env or github context to access variable values in parts of the workflow that are processed before jobs are sent to runners.