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.

[rohit-gohri]

I have a very similar usecase/workflow. I have a monorepo that deploys multiple services to GCP across 3 environments (dev/stage/prod).
The deployments for all the services happen in parallel across 5 different jobs in single workflow. Me and my team treat that as a single deployment, but Github treats it as n different deployments. I think it makes more sense to just group all those deployments as a single event in the UI and Deployments page.

[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?

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