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).
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.
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)
@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.
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.
@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)
If setting the environment attribute dynamically is still not working in the main workflow, it might be helpful to consider using reusable workflows when dynamically configuring the environment, as described in this related thread. It worked for me, and my example is at the bottom of the thread.