How do I reference the deployment environment name in Github Actions workflow YAML?

Question

I would like to access the deployment environment name in my Github Actions workflow YAML. Here is an example:

jobs:
  example:
    runs-on: ubuntu-latest
    environment: "foobarbaz"
    ...

    steps:
      ...
      - name: Terraform Check Format
        id: terraform-fmt
        # what should I use here instead of "????" to get "foobarbaz"?
        run: terraform -chdir=terraform/stacks/${{ ???? }}/${{ matrix.stack }} fmt -check

Answer 1

With your specific example, do something like:

name: Terraform Workflow
on:
    push:

jobs:

  # Create a job at the top of your workflow with some logic
  # to determine the name of your environment,
  # and set that environment as a variable you send to $GITHUB_OUTPUT

  set-foobarbaz-environment:
    runs-on: ubuntu-latest
    outputs:
      ENVIRONMENT_NAME: ${{ steps.set-env-step.outputs.ENVIRONMENT_NAME }}
    
    steps:
      - id: set-env-step
        run: echo "ENVIRONMENT_NAME=foobarbaz" >> $GITHUB_OUTPUT

 example:
   # Reference the output variable with `needs` syntax wherever you want to use it,
   # including as a value in a job's 'environment' key.
   - name: Terraform Check Format
     id: terraform-fmt
   # what should I use here instead of "????" to get "foobarbaz"?
     run: terraform -chdir=terraform/stacks/${{ needs.set-foobarbaz-environment.outputs.ENVIRONMENT_NAME }}/${{ matrix.stack }} fmt -check

Summary:
As of this writing, you can't directly access either the value defined via the environment: key nor can the environment: key access environment variables defined at any level. So, there is no built-in Github Actions way to do this. All is not lost, however - you can set an output variable that you can use in both the environment: key and in your steps. This will ensure your code always uses the same name assigned to your github environment, somewhat indirectly.

The basic logic is as follows:
1. Create a job dedicated to setting an $ENVIRONMENT_NAME variable managed with $GITHUB_OUTPUT (note - NOT a $GITHUB_ENV variable).
2. Reference this $ENVIRONMENT_NAME in any following job, including by the environment: key or any downstream code you'd like to ingest the environment name as a parameter that modifies execution.

The more general form, allowing for dynamic assignment, is something like:

name: Sample Environment Key Detection Workflow
on:
    push:

jobs:

  # Create a job at the top of your workflow with some logic
  # to determine the name of your environment,
  # and set that environment as a variable you send to $GITHUB_OUTPUT

  set-environment:
    runs-on: ubuntu-latest
    outputs:
      ENVIRONMENT_NAME: ${{ steps.set-env-step.outputs.ENVIRONMENT_NAME }}
    steps:
      - id: set-env-step
        run: |
          # or whatever logic you want to determine environment
          if [[ "${GITHUB_REF_NAME}" == "main" ]]; then
            echo "ENVIRONMENT_NAME=production" >> $GITHUB_OUTPUT
          else
            echo "ENVIRONMENT_NAME=test" >> $GITHUB_OUTPUT
          fi

  # Reference the output variable with `needs.` syntax wherever you want to use it,
  # including as a value in a job's 'environment' key.

  detect-environment:
    needs: set-environment
    environment: ${{ needs.set-environment.outputs.ENVIRONMENT_NAME }}
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to ${{ needs.set-environment.outputs.ENVIRONMENT_NAME }}"

      # will only run if your environment resolved to 'production'
      - if: ${{ needs.set-environment.outputs.ENVIRONMENT_NAME == 'production' }}
        run: echo "This is a production deployment"

      # will only run if your environment resolved to 'test'
      - if: ${{ needs.set-environment.outputs.ENVIRONMENT_NAME == 'test' }}
        run: echo "This is a test deployment"

It's a shame that Github Actions doesn't allow for accessing the environment name that's set in the jobs environment key. I'd be very curious if anyone comes up with something more elegant and/or readable than what I've done above.

If you prefer not to create an entire job for this process, you can simply replicate the branch detection code throughout your scripts, but this is in violation of DRY.