Support for use of environment variables in if expressions

It would be nice to be able to use environment variables in if conditionals.

While I can use an if condition in a runs definition, the step will still be marked as run (successfully, perhaps). If we could use if conditionals for the same thing, the step would be marked as ignored.

13 Likes

Any progress on this? When you’re reading this documentation it sounds like env context is usable but following code still fails.

jobs:
  example-job:
    env:
      EVENT_LABEL: example-label
    if: github.event.label.name == env.EVENT_LABEL
    runs-on: ubuntu-latest
    steps:
      ...

causes

Your workflow file was invalid: The pipeline is not valid. Unrecognized named-value: 'env'. Located within expression: github.event.label.name == env.EVENT_LABEL

Setting value directly works like expected:

if: github.event.label.name == 'example-label'
5 Likes

It might be that job-level “env” context is populated after job-level “if” is tested. It’s a long shot, but i’d try if setting EVENT_LABEL at workflow-level “env” would help.

If not, you still can get (kinda) wanted behavior by moving check step-level:

check-label:
 runs-on: ubuntu-latest
 env:
LABEL_FOO: foo
LABEL_BAR: bar
LABEL_HELP: needs-help
LABEL_BOOM: user-pc-exploded
steps:

 - run: do-foo-thing
if: github.event.label.name == env.LABEL_FOO

- run: do-bar-thing
if: github.event.label.name == env.LABEL_BAR

- run: post-on-stackoverflow
if: github.event.label.name == env.LABEL_HELP

- run: send-flowers --color random
if: github.event.label.name == env.LABEL_BOOM

Most likely not a solution for everyone; it starts workflow, after all, which might be unwanted for few reasons. Packing N different, complex tasks into single job can be meh too. But if various simple tasks share some step(s), it might be nice.

A prior step can be used as an adapter for environment variables and secrets, eg…

name: WORKFLOW
env:
   ENV_FOO: default_foo
...
build:
  name: Build
  runs-on: ...
  steps:
  ...
  - name: Initialize workflow variables
    id: vars
    shell: bash
    run: |
        FOO=$ENV_FOO
        if [...]; then FOO=alternate_value
        echo ::set-output name=FOO::${FOO}
        unset HAS_SECRET
        if [-n $SECRET]; then HAS_SECRET='true' ; fi
        echo ::set-output name=HAS_SECRET_TOKEN::${HAS_SECRET}
env:
SECRET: "${{ secrets.SECRET }}"
  - name: Use vars
    if: ${{ steps.vars.outputs.HAS_SECRET }}
    shell: bash
    run: echo "${{ steps.vars.outputs.FOO }}"
...

You should be careful to not actually expose any secret content as an text or output (as any future step will have access to it). You can use the usual env or input techniques to re-supply any secret to a later step, where needed.

An example workflow using this technique can be seen at <https://github.com/rivy/rust.lsd/blob/a7b0ecdd022a061a59df41526cb7543e8ed82022/.github/workflows/CICD.yml>.

It works on the step level, but not on the job level.

Any news, GitHub, on whether this will be supported soon?