How to set environment attribute dynamically in a workflow?

Code to Cloud GitHub Actions
#1

Hello, in the settings of my repository I created 2 environments: development and production. I also have 2 branches of the same name. I want my workflow to execute in the corresponding environment (so as to grab the correct git secrets).

This is what I have:

jobs:
  branch-based-execution:
    name: Run external workflow
    environment: ${{ github.ref }}
    runs-on: ubuntu-latest
    steps:
      - name: Echo env var
        env:
          my_var: ${{ secrets.my_var }}
        shell: bash
        run: echo $my_var

However, I get the following error on the environment line:

Unrecognized named-value: ‘github’. Located at position 1 within expression: github.ref

Looks like I can’t use github context to set the environment attribute. Is there a way to set the environment of the workflow dynamically? Thanks!

4 Likes
#2

I have this issue as well.

I note that in this thread, @cschleiden suggests using something like

  jobs:
    deploy:
      environment: ${{ github.event.inputs.env_to_promote_to }}

and he works for github as far as i can tell.

I created the following minimal example repo: GitHub - dradetsky/context-param-environment: gha related example. The intention was to do exactly what @cschleiden suggested. My workflow starts as

name: manual stuff
on:
  workflow_dispatch:
    inputs:
      myenv:
        description: the env to run on
        default: dev
        required: true

jobs:
  some-job:
    environment: ${{ github.event.inputs.myenv }}

Which looks like what Christopher was recommending, although I’m not very smart so maybe I missed something. Anyhow, attempting to run that produces

The workflow is not valid. .github/workflows/manual-workflow.yaml (Line: 15, Col: 18): Unrecognized named-value: 'github'. Located at position 1 within expression: github.event.inputs.myenv

I’m kind of confused.

FWIW, my use-case is to allow other developers in my org to manually trigger runs of our e2e test suite against various versions of our platform (i.e. run them against the dev version, or the staging version, or whatever), but also to programmatically trigger the e2e tests at other times.

#3

Hi @dradetsky, I spent quite some time trying to solve this before and the problem is that currently is not possible to use expressions or any type of logic in the environment name. You can do it in the environment url but not in the name. So I came to the conclusion that dynamic environments in a single workflow are not possible for now.

For your use case to trigger tests on different platforms you can either have 1 workflow per platform and put one env in each workflow, or you can have different branches for each platform and have a step in your workflow that sets up the variables based on the branch name (using an if statement inside Bash, there are examples on the internet. in this alternative you wouldn’t use environments at all)

#4

@lautaromss thanks for the info. Did you get a response from somebody at github or look at the code that processes that expression? Or were you simply unable to get it to work? The reason I ask is that given that @cschleiden said, I’m inclined to think that it is github’s intention that it should be possible to do this, so maybe the fact that you & I can’t get it to work is a bug. In fact, I would assume that given that @cschleiden gave that example, it did in fact work in the past, and the fact that it doesn’t work now is a regression.

I am of course aware I can work around this particular use case with one workflow per environment. However, I also wanted to use this for deployments to those particular environments (and take advantage of the environment protection rules). Now all of a sudden I’ve got 5 e2e test workflows, and 5 e2e deploy workflows. This is starting to seem prohibitive. I also want to run integration tests against a deployed instance, so maybe that’s another 5. Also, my tool for programmatically adding the the workflows to various repos used by developers doesn’t currently support adding 5 versions of the same file with different parameters, so I would have to add that feature. Maybe there are other aspects of problem that I haven’t even thought of yet.

Basically, I’d really like to check if it was github’s intention to allow setting the environment from a context expression before I dive down this rabbit hole. It looks deep.

Set environments at runtime
#5

@lautaromss actually, we were both wrong, it is solvable. Of course, it’s all @cschleiden’s fault for giving the example

 jobs:
    deploy:
      environment: ${{ github.event.inputs.env_to_promote_to }}

when in fact it should have been

 jobs:
    deploy:
      environment:
        name: ${{ github.event.inputs.env_to_promote_to }}

And not documenting this elsewhere. However, looking at his own repo GitHub - cschleiden/actions-examples, we see the following sample code

on:
  workflow_dispatch:
    inputs:
      envName:
      
      
jobs:
  deploy:
    runs-on: ubuntu-latest
  
    environment:
      name: ${{ github.event.inputs.envName }}

Trying that out on my own example repo I made the following change whereupon I was able to run the workflow with the param set to both dev and prod

Anyhow, @cschleiden, this definitely seems like a docs issue to me. It took me way too long to figure this out IMO, and @lautaromss was under the impression it was impossible entirely. I’m not totally sure exactly how the docs should be changed though.

#6

@dradetsky huh I was pretty sure I tried that and didn’t work, I guess I didn’t. I think it’s a bug then because the keyword “environment” can be used by itself for the name of the environment if you put a literal string, but it gives a syntax error when going for a context expression.

Me and my team did a pretty big workaround for this in our projects lol (setting up the environment variables manually with if statements)

#7 
 environment: ${{ github.event.inputs.env_to_promote_to }}

not working is a bug and is being fixed.

#8

Hi @cschleiden, we’re really looking forward for this issue to be fixed, do you have an expected time for it to be solved? Thank you!

#9

@jbatet-uz That should’ve been fixed back in April. Is it still not working for you?