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.

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

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. 😅

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?

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

Thank you for the reply!

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

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.

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.

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

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.