Enabling Github Environments on the workflow level

[michhyun1]

It seems as if I am only able to enable github environments on the Job level. I want to deploy my environment once and have my entire workflow run under that environment.

My use case is the following:

I have a CI workflow that includes one workflow and ~10 jobs (and more will be added soon). Every single job requires a Github Secret. When a pull request is submitted to our main branch, GHA should require a manual deployment to our github environment called CI Workflow and once the approval is done - trigger the workflow and run the 10 jobs.

However, since the environments is only on the job level, I have to attach the job.job-id.environment property to each job. That means, when an external contributor submits a PR against our main branch, it looks like this:

The PR is here

Is there a way to deploy the environment only one time, and then run all of the jobs under that environment?

[chrispat]

@michhyun1 Could you provide some additional information on your scenario? From what I see it feels like you are using environments with approvals and secrets to support a scenario that we have not thought about, but I am not 100% sure exactly what that is.

[chrispat]

@michhyun1 Interesting scenario. I don't think that will work without other changes as we won't send secrets to runs triggered from forks or external contributors that run against the code from that PR. We do have the pull_request_target event which runs on the PR event but uses the code from the target branch rather than the PR branch.

@rohit-gohri That is good feedback. There isn't anything you can do today to support that scenario but it is something we can consider for the future.

[michhyun1]

I thought a PR that is deployed to an Environment should have access to the Environment's secrets, regardless of whether or not it is a PR from a forked repo or not?

I plan to attach my secrets to an Environment, then deploy the external contributor PR to the Environment (once someone manually approves the deployment). The PR should have access to the Environment's secrets, correct?

[chrispat]

@michhyun1 at the moment we always treat PRs from fork the same regardless when using the pull_request event as it will checkout the code from the PR by default. You could make it work with the pull_request_target event but you will need to be very careful in how you execute code from the untrusted actor.

[chrisponton]

+1 here too.

I am having this issue after implementing 10+ reusable workflows in a mono repo to be able to deploy to multiple environments.

I would like only the caller workflow to request approval, which means adding the environment property to this. But each called workflow needs access to different secrets based on the environment. If I pass the environment down and set it in the next jobs, the workflow picks up the correct secrets for that environment deploy, but I get numerous requests for approval, which means my pipeline doesn't flow like I want.

Any news on this?

[ccolella-mdc]

+1 here too.

I am having this issue after implementing 10+ reusable workflows in a mono repo to be able to deploy to multiple environments.

I would like only the caller workflow to request approval, which means adding the environment property to this. But each called workflow needs access to different secrets based on the environment. If I pass the environment down and set it in the next jobs, the workflow picks up the correct secrets for that environment deploy, but I get numerous requests for approval, which means my pipeline doesn't flow like I want.

Any news on this?

My organization has this exact same issue. Either being able to set the environment on the called reusable workflow or on the job that calls the reusable workflow would solve it for us.

[HariSekhon]

I am also finding this frustrating... because I need to protect the deployment environments with reviews and when the workflow is consisting of different jobs that need access to the environment secrets, the workflow requires multiple approvals to get it to proceed, which is a waste of time.

I want deployment environment to be able to be configured at the workflow level so that once I have approved the environment deployment all the jobs in that workflow run should progress without repeatedly prompting me for every job in the flow.

Right now I've had to rewrite a relatively large 450 line workflow of multiple jobs which appeared nicely in the UI with different job steps into a single monolithic job to avoid this multiple approvals issue due to the lack of being able to set the deployment environment at the workflow level and approve it once in the UI.

On a related note, deployment environment support should be added to the reusable workflow level too, see:

#18085

[dkirrane]

+1 I'm looking for same.
And it would be good if reusable workflow could just inherit both the environment and concurrency from the main workflow.

e.g.

name: Stage

on:
  pull_request:
    branches:
      - main

concurrency: stage_environment

environment:
  name: stage_environment

jobs:
      
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/workflow-cicd.yml@main
    secrets: inherit
    concurrency: inherit
    environment: inherit

[HariSekhon]

The concurrency I think is ok because it can lock it at the calling workflow level.

But the lack of environment pass-through is a clear gap in the lack of maturity of reusable workflows.

[HariSekhon]

This is such a tedious issue I've just had to rewrite a non-trivial 450 line workflow into a single job to minimize it to one approval for the workflow since each approval takes at least 3 clicks per job otherwise and wastes time waiting for approvals at each job/stage too.

You can't even automate around this with GitHub CLI, nor even with the Rest API, so I've just raised a request for them too:

cli/cli#5773

#18088

[Hronom]

Hello, same here especially useful for GitOps flow. When you wanna not start docker image build until user not approve this.
So I need provide possibility for the user to approve docker build and deploy and make sure that only one deployment is created.

[mkatanski]

Hello. Any news on that? Its the end of 2023 and I also have the same problem. I consider one workflow with multiple jobs as deployment and it would be nice to assign environment on workflow level.

[Hronom]

Hello GitHub, can you please find time and check this functionality in GitLab(it's your competitors). Hope you get inspiration. Thanks!

[gionn]

https://docs.gitlab.com/ee/ci/environments/#access-an-environment-for-preparation-or-verification-purposes

[e965]

It's very strange that something like this wasn't done from the beginning. At the moment it's the only thing stopping me from using Environments.

[ltrung]

Any update on this? This causes frustration for our external contributors.

[amrod]

I have the same issue. It's incredible this isn't at the top of Github's TODO list.

[DanielShepherd-RL]

Would love to see this functionality.

[peterramsing]

+1 for adding this functionality.
We are using Environments and then we have these one-off TEST_ENV1_ROOT_URL variables that are awkwardly in our repo and it makes composable actions harder.

[stewartadam]

This is made particularly awkward for using environments with re-usable workflows because environment property on jobs is not supported if using is present. So as best I can tell isn't a way to load environment secrets in a triggered workflow and pass them to callable workflows, that aren't themselves aware of the environments.

[DavidPriceNBS]

+1

[jzila]

I have a similar use case - I use jobs with a matrix to deploy all my containers using the same job spec, and they all need environment secrets. Unfortunately because of the job-environment-deployment coupling, this creates deployments for every workflow run, and they're effectively never "active".

A workflow-level environment spec would allow all the nice concurrency/DRY semantics of jobs to apply, while only creating one deployment and allowing all jobs to access environment-specific variables and secrets.

[gguillen]

+1 Need this

[gavinclarkeuk]

Definitely need a solution to this. We have a multi job deployment process which we use reusable workflows for. Because of the (seemingly arbitrary) limitation on setting environment on jobs if using is present we can't set the environment in any meaningful way that doesn't result in a single deployments being treated as multiple deployments.

We need to be able to either set environment at a workflow level, or lift the restriction on setting it on a job when calling a reusable workflow.

For our use case we aren't really using environment secrets, because the lack of org wide environments makes that impractical. However we do want to use environment protection rules and approvals. The extra UI feedback would be useful too.

[markfickett]

This also affects timers. We deploy to our production environment after a 24h timer. (Each environment also has some of its own secrets and variables.)

However, the prod deployment consists of deploy backend -> migrate backend db and build frontend w/ production config -> deploy frontend, four jobs with two needs. So the 24h timer waits once for the deploy backend and build frontend steps, and then again for the migrate db and deploy frontend steps. This is similar when manually starting the waiting production jobs if we want to deploy right away; I have to click 'start waiting jobs', wait for the first two production jobs to complete, and then click 'start waiting jobs' again.

Instead, I want the timer to run once for everything the workflow is going to do in the production environment. So I would merge to main, the staging environment deployment jobs would run, and then 24h later the production environment deployment jobs would all run in order without additional waits.

[gerrycampion]

I also have this similar problem, but I have a workaround that:

• allows for multiple parallel jobs using the env vars
• requires only a single approval

Using this: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs

You can replace this code:

jobs:
  job1:
    runs-on: ubuntu-latest
    environment: PROD
    steps:
      run: echo ${{ vars.VAR1 }}
  job2:
    runs-on: ubuntu-latest
    environment: PROD
    steps:
      run: echo ${{ vars.VAR2 }}

With this code:

jobs:
  copy_vars:
    name: Copy environment vars from Github Env Vars to outputs to avoid multiple approvals
    runs-on: ubuntu-latest
    environment: PROD
    outputs:
      VAR1: ${{ steps.vars.outputs.VAR1 }}
      VAR2: ${{ steps.vars.outputs.VAR2 }}
    steps:
      - id: vars
        run: |
          echo "VAR1=${{ vars.VAR1 }}" >> "$GITHUB_OUTPUT"
          echo "VAR2=${{ vars.VAR2}}" >> "$GITHUB_OUTPUT"
  job1:
    runs-on: ubuntu-latest
    needs: copy_vars
    steps:
      run: echo ${{ needs.copy_vars.outputs.VAR1 }}
  job2:
    runs-on: ubuntu-latest
    needs: copy_vars
    steps:
      run: echo ${{ needs.copy_vars.outputs.VAR2 }}

If you do copy_vars and pass the vars as inputs to a reusable workflow containing job1 and job2, then you no longer need needs: copy_vars on each job.
There may be a way to generalize this for any number of env vars using something like jq? Any tips to generalize or simplify this would be nice.

[gavinclarkeuk]

Whilst this works for extracting the environment variables, it still isn't ideal because if one of the deployment jobs fails the environment deployment will still look at though it succeeded because the copy_vars worked.