Concurrency group does not support environmental variables?

[mikeschinkel]

Just checking to see if others can confirm or refute my analysis here.

It seems that concurrency group does not support environmental variables?

Given this segment in one of my workflow files:

env:
   EXTERNAL_SERVER_IP: <redacted>
concurrency:
   group: my-build-${{ env.EXTERNAL_SERVER_IP }}-${{ github.ref_name }}

I get this Annotation error:

Invalid workflow file: .github/workflows/ci_push.yaml#L18
The workflow is not valid. .github/workflows/ci_push.yaml (Line: 18, Col: 14): Unrecognized named-value: 'env'. Located at position 1 within expression: env.EXTERNAL_SERVER_IP

I would like to use environment variables to stay D.R.Y. as I also use that variable elsewhere, but it seems maybe the GitHub Actions developers have to explicit implement every feature for every other feature, i.e. environment vars within concurrency, in this case?

Can anyone confirm this, or help me understand what I might be doing wrong?

And if in fact concurrency does not currently support environmental variables, what is the appropriate repo where I can submit an issue and/or maybe even a pull request?

Thanks in advance.

[airtower-luna]

This is documented in the description of the env context:

You can use the env context in the value of any key in a step except for the id and uses keys.

concurrency is not part of a step, so env isn’t available.

[mikeschinkel]

Thank you for the reply and explanation.

Is there any other way to define constants that would be in scope throughout the entirety of the YAML file? github.event.inputs.* seems to have full YAML scope for workflow_dispatch, but inputs do not seem to work for on:push.

-Mike

[airtower-luna]

For workflow-level concurrency the documentation says that only the github context is available, so no. For job-level concurrency I suppose you could use another job to create an output and use that. 😅

[mikeschinkel]

Thanks again, but unfortunately that does not sounds like a great option. But then your emoticon signaled that.

Do you mind if I ask my seconds question again from my original post?

What is the appropriate repo where I can submit an issue and/or maybe even a pull request?

[airtower-luna]

Considering that this is about the workflow syntax itself, I guess the Actions section of the community organization discussions would be the right place: Discussions · github-community · GitHub

[mikeschinkel]

Thank you for the reply!

[nicholasbergesen]

Hi @mikeschinkel

You could make use of reusable workflows to achieve what you’re trying to do.

caller.yml

on:
  push:
jobs:
  call_job:
    uses: ./.github/workflows/called.yml
    with:
      EXTERNAL_SERVER_IP: <redacted>

called.yml

on:
  workflow_call:
    inputs:
      EXTERNAL_SERVER_IP:
        type: string
        required: true
jobs:
  do_job:
    runs-on: ubuntu-latest
    concurrency:
      group: my-build-${{ inputs.EXTERNAL_SERVER_IP }}-${{ github.ref_name }}
    steps:
      - run: echo step

[mikeschinkel]

Hi @nicholasbergesen —

Thank you for taking the time to offer a suggestion.

The irony of your suggestion, though, is that is exactly what I was doing prior to running into the unworkable limitations of reusable workflows and thus had to unravel that work and just go back to independent workflow files. And it was there I found myself trying to use environment variables as an alternative to the input values I had been using.

Seems I am damned if I do, damned if I don’t! 😢

So I made this feature request.

[nicholasbergesen]

Hi @mikeschinkel

An alternative workaround could be to use secrets. Add a secret in the repo/org and then reference it in the workflow using ${{ secrets.EXTERNAL_SERVER_IP }}. This would make the value accessible throughout the workflow similar to the behavior of const you proposed. It’s not the most elegant solution but it could give you the outcome you’re looking for.

[mikeschinkel]

Hi @nicholasbergesen —

Thank you again for the suggestion. Yes, secrets are certainly a creative stand-in for constants.

Unfortunately for my use-case they are unworkable for a few reasons:

1. I specifically need the IP address of a vCenter server which I used to compose URLs to that vCenter server in the logs for use by the workflow user. If I used a secret it would redact that information and replace with asterisks thus making the URLs unusable and making it much more work for workflow users who need to visit the appropriate vCenter server after the workflow runs.

2. Also my work is at a large technology company and GitHub administration is managed by a DevOps department, not by me. I do not have admin permissions to add secrets and adding non-secret secrets just for developer “convenience” is not something that team wants to manage and keep track of given the huge humber of secrets they already maintain and (my guess) especially since GitHub Secrets don’t have an associated description field to help inform the purpose of secrets for future maintainers…

So yes, I agree secrets are a great workaround for constants when someone 1.) does not need to see the value while or after running a workflow and 2.) they have admin permissions to add and manage secrets themselves.

Unfortunately, for my use-case however, using secrets ends up being a non-starter. 😢

-Mike

[mikeschinkel]

Hi @nicholasbergesen —

Thanks to your persistence in trying to identify a workaround for me you inspired me to search the docs to see if there were any other potentials solutions to address this need that actually fit my use-case. And lo-and-behold, there is!

I was able to create a matrix strategy with one option like the following workflow snippet, and it worked!

strategy:
  matrix:
    EXTERNAL_SERVER_IP: [<redacted>]
concurrency:
  group: my-build-${{ matrix.EXTERNAL_SERVER_IP }}-${{ github.ref_name }}

Just thought I would close the loop on this for the benefit of anyone in the future who has the same need and googles for a solution.

Still, adding a constant feature to Gihub Action workflows would be much better as a const's existence in a workflow would correctly imply why it is being used whereas a matrix might confuse future maintainers who miss any comments explaining why a one-element matrix is being used.

[nicholasbergesen]

Hi @mikeschinkel

That’s a really creative solution, it never crossed my mind to do that. I’m glad you’ve found a way forward!

Thank you for sharing it.