Using environment in github actions without creating Deployments

[connor-luna]

I have environment-specific secrets defined which I'd like to reference from my Action. I think this requires me to set an environment for the job. The problem is that it seems like as soon as I set an environment, there's no way for me to prevent an associated Deployment from being created, which I don't always want. Is there a way to access environment-specific secrets without having the job create a Deployment?

[thiswallz]

what do you mean by accessing env variables? those are just there for your jobs to consume them, they are not triggering anything whatsoever, if you can share your yml would be nice

[connor-luna]

Not env variables, but environment secrets. I want my workflow to be able to access those secrets without creating an associated Deployment.

[thiswallz]

that is quite streight forward, ${{ secrets.NPM_TOKEN }}

check : https://github.com/thiswallz/react-custom-product/blob/main/.github/workflows/publish-to-npm.yml

[connor-luna]

No, I want to be able to access secrets specific to a certain environment. This requires me to specify an environment for the job, but specifying an environment causes deployments to be created.

[thiswallz]

yup now I get it, can you share your yml file?

[ossanna16]

Hi there @connor-luna and welcome to our community 😄. Thanks so much for asking a great question!

[CodingLife1024]

You can access environment-specific secrets in GitHub Actions without creating a Deployment by using the env context directly within your job steps.

name: <example>

on:
  push:
    branches:
      - main

jobs:
  access-secrets:
    runs-on: ubuntu-latest

    steps:
      - name: Access secret
        run: echo "The value of MY_SECRET is ${{ secrets.<yoursecret> }}"

[Blitheness]

There's nothing environment-specific about this suggested workaround, this is accessing standard (non-environment specific) Actions secrets.

[jgreat]

I would also love it if we could use Environments for setting up repeatable workflows without every Job that references an environment: in Actions triggering a "Deployment" message.

I have a complex multi-job setup in a monorepo that utilizes matrices for concurrent steps. These matrix jobs reference an environment: like dev or alpha to segregate configuration required to build and deploy the artifacts as part of a CD build.

The problem is that I have, is my workflow creates 40+ jobs related to an environment:. Each of these jobs needs discreet secrets/config
for each environment in my workflow. Each one of these jobs puts a user temporarily deployed to dev 2 days ago Inactive message in a PR. I not sure what value these messages have (or what Deployments API actually provides in an GH Actions world).

Each update to a PR adds another set of 40+ messages into the PR history. This completely buries any conversion in PR because of the interface hiding messages for you.

This is a public repo, so you can see the workflow here:
https://github.com/mobilecoinfoundation/mobilecoin

Here's an example PR where Deployments noise, hides active important conversations.
mobilecoinfoundation/mobilecoin#2844

[jackmpcollins]

You might be interested in this discussion "Enabling Github Environments on the workflow level" https://github.com/orgs/community/discussions/14417

[kennethjmyers]

At the very least we should be able to hide these messages so that we can see the conversations. Here's someone else suggesting this
https://github.com/orgs/community/discussions/58018

[akwodkiewicz]

Same issue discussed here: https://github.com/orgs/community/discussions/52610

[menzenski]

We also find this frustrating. We run a number of environment-specific checks as part of pull request tests and they are shown in the UI as having deployed to environments where they have not truly been. It would be great to have the ability to distinguish "prepare deployment" or "verify deployment" or similar read-only operations from an actual "deploy to environment" update action.

(worth noting that there's prior art here: GitLab supports this distinction: https://docs.gitlab.com/ee/ci/environments/#access-an-environment-for-preparation-or-verification-purposes)

[tinogo]

I really like Gitlab's approach to this! :)

As it current stands with Github is this regard, things get even more annoying, when you've additionally configured deployment approvals.
There it not only polutes the PR UI with these "Pseudo-Deployments", but you also need to approve each and every job which uses an environment, but isn't really deploying anything...

[al-v-in]

Same frustration here. I need to access Environment secret for a Terraform Plan job, but of course nothing is being deployed at that stage.

And to make it worse we have have enabled human approval for some environments so we have to manually approve Terraform plans, which is obviously a bit daft and a waste of time

[mkarbo]

Same issue here

[SamiMaj]

Another thumbs up for this issue. It would be nice to get some feature that would let you specify if the workflow should create a "deploy" or not

[ThomasMarcelo]

Same issue! I just want to have access to the variables per env.

[yuvmen]

same issue, I have a workflow which deploys logic, and one which deploys infra using terraform - both use env secrets but now both look the same and cause "deployments" to be created.
I want to be able to control it - ideally decide "deployments" are only created for one of them or at the very least control some label or text explaining what sort of deployment happened.

[nagibyro]

Same issue, for us we have a docker image hosted in ECR but only in our prod account. We want to use it as a service container in our PR workflow test job but we need to login to ECR and get the docker password and secret in prod. So we have a job before the tests job that uses the "production" environment to get secrets for logging in to ECR. We haven't deployed anything just need the outputs but now all our PR's have marks saying they were deployed to prod even though they haven't been. 😞

Edit: Clean up wording

[ilmax]

Same issue here, I'd like to decide when a successfully run action that references an environment creates or not a deployment. Mostly because I use environment over variables because they have approval.

[smtheard]

same problem, anyone have a workaround? it's super annoying to have a terraform plan always trigger a "deployment" when nothing is being deployed at all.

[dmt195]

Same here. I'm doing a dry run (Terraform) deploy into the target environment as part of a PR but then says it was deployed. It seems like a missing piece of the puzzle.

[bradyclifford]

Same issue.

[Kolahzary]

We have same issue here,
Trying to create a workflow to build a front-end project with staging and production configurations in a matrix. there's no way to use the environment variables at the build time and prevent GitHub from assuming that it is deployed!
Probably the easiest workaround is to hard-code the environment variables inside the matrix till GitHub resolves this issue

[Kolahzary]

found some workaround here: actions/runner#2120

[ilmax]

I also found that workaround but it's not ideal because when a deployment is created, it still overwrites the last effective one. I.e. if you want to check the latest deployment on an environment, with the workaround in place it will point to the wrong deployment if I read that correctly.
I really wish a flag will be implemented to allow us to decide if a run creates or not a deployment

[cnnranderson]

We also have a lot of frustration with this coming from the Terraform side. However, there's an another piece that is also adding friction. If you use these for deployment gates with their Protection rules, for some applications that require build-time secrets/variables, this can create multiple jobs that require approvals at each step (one for build stage, another for deploy stage). This adds unnecessary friction to the deploy process for getting a release out.

This, combined with the terraform headaches, adds so much additional pipeline overhead that it makes the Environment feature more of a burden than a benefit. Consider the following:

2 Workflows: Terraform Plan/Apply, Application Build/Deploy

1. Merge to main -> Triggers both workflows
2. Terraform workflow: Job - Terraform Plan
   • Requires environment to review existing state in Cloud (nothing gets modified, but secrets are used to acquire OIDC id-token or compose relevant secrets in tfvars)
   • If protection rule, requests approval
3. Terraform workflow: Job - Terraform Apply
   • Requires environment again
   • If protection rule, requests approval (again)
4. Application Build/Deploy workflow: Job - Build Application
   • Requires environment
   • Requests approval (again...)
5. Application Build/Deploy workflow: Job - Deploy Application
   • Requires environment
   • Requests approval (again.....)

This would end up requiring 4 approvals at the bare minimum. Multiply this by X number of environments you have, and you're going to go crazy. There's really no way to get around this for some applications without creating an absurd amount of noise (notifications, PR "deployments", etc), multiple "vanity" Environments that are strictly used for approval gates, or over complicated "hacky" workarounds as proposed above.

Finally, it'd be great to reduce the number of deployments because we want to be able to easily compare what is recently deployed vs. previously deployed. While we already leverage tags for this, having those be more aligned with actual deploymnets would add a lot of value.

Edit:
Wanted to demonstrate the "vanity" environment I mention above:

  terraform-review:
    name: 'Terraform Review'
    if: ${{ needs.terraform-plan.outputs.tfplanExitCode == 2 && (github.ref_name == 'main' || github.event_name == 'workflow_dispatch') }}
    runs-on: ubuntu-latest
    needs: [terraform-plan]
    environment: ${{ inputs.environment == 'prod' && 'prod-review' || inputs.environment == 'test' && 'test-review' || 'dev-review' }}

    steps:
      - name: Plan Review
        run: echo "Approval step to review Terraform Plan in Job Summary"

This demonstrates a Job that gives you time to review the plan output and review proposed changes. The dev-review/test-review/prod-review are the "vanity" Environments with the protection rules to reduce the number of approval check-ins. They contain no secrets/variables.

[avbhandaru]

+1 here, especially this comment as an idea:
https://github.com/orgs/community/discussions/36919#discussioncomment-11142743
This PR timeline noise is pushing my team to just leverage GitHub action environments to connect to our VPN once and pull secrets AND medium term move to on-prem. All we want to do is run a terraform plan for a PR without all the added noise.

[saada]

The best workaround I came up with was setting the default vars and secrets to match the environment I wanted.
It's a bit of value duplication but works fine.
Really hope Github solves this properly and gives us a way to mark a workflow as an actual deployment.

[dkowalcz-sec]

I came up with that workaround which works pretty well for me:

name: 'Validate Only'

permissions:
  contents: read
  deployments: write

on:
  workflow_call:
      github_environment:
        description: GitHub environment
        required: true
        type: string

env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

jobs:
  validate:
    name: Validate
    runs-on: ubuntu-latest
    environment:
      name: ${{ inputs.github_environment }}

    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v4

      - name: 'Run command which requires access to environment variables'
        run: echo "Do something"

  cleanup_deployment:
    name: 'Cleanup deployment'
    runs-on: ubuntu-latest
    needs: validate
    if: always()
    steps:
      - name: 'Get deployment ID'
        id: get-deployment
        run: |
          DEPLOYMENT_ID=$(gh api repos/${{ github.repository }}/deployments \
            --method GET \
            --field sha=${{ github.sha }} \
            --field ref=${{ github.ref_name }} \
            --field task=deploy \
            --field environment=${{ github.event.inputs.github_environment || 'dev' }} \
            --jq '.[0].id // empty')

          echo "Found deployment ID: $DEPLOYMENT_ID"
          echo "deployment_id=$DEPLOYMENT_ID" >> $GITHUB_OUTPUT

      - name: Deactivate GitHub deployment
        if: always() && steps.get-deployment.outputs.deployment_id != ''
        uses: chrnorm/deployment-status@v2
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          deployment-id: ${{ steps.get-deployment.outputs.deployment_id }}
          state: 'inactive'

      - name: Delete GitHub deployment
        if: always() && steps.get-deployment.outputs.deployment_id != ''
        run: |
          gh api repos/${{ github.repository }}/deployments/${{ steps.get-deployment.outputs.deployment_id }} --method DELETE

[dkowalcz-sec]

Long story short, I remove the deployment immediately after running the required, non-deploy related commands

[Tsingis]

Hacky but exactly what I've done too...

[therajumandapati]

Given how many people are having this issue since 2023, I'd imagine GitHub prioritizes this issue. We're also struggling with the same mess everyone is.

[hansfuchs]

I can't believe this still isn't possible. We wanted to structure our variables and secrets for our monorepo without having to add an app-specific prefix every single time.

We simply wanted to build each app in our pull request action to verify it still works, but this creates a deployment for every single app, even though nothing is being deployed.

[xaviergmail]

This is something our organization also desperately wants. There are several use cases where we want to use "environments" to fetch secrets/variables during build-time but without creating a github deployment, such as building for every stage at the start of a workflow, and conditionally deploying it in later stages, such as waiting for a test suite or manual approval.

Also, we use reusable workflows (on: workflow_call) extensively which may have multiple jobs within it. It's currently not possible to specify an environment on an entire reusable workflow call. This means that every job within the reusable workflow must specify environment:. For environments with manual approval requirements, this means we have to manually approve each and every job in the reusable workflow, such as approving "production" deployments five times for a single deployment.

We have resorted to splitting it out into a production_approval environment which has the manual approval step, as a no-op job that runs in the environment for approval, before the deployment jobs, then setting our secrets and variables on a production environment which is used by the deployment jobs themselves. But this approach is silly as it opens the door for CI jobs to run using environment secrets without requiring approval.

[bhidalgo-apolitical]

This is something that should come by default with GitHub actions, but surprisingly and even after 3 years of complaints the feature is not there. It has a bad design, and it's even more noticeable for big monorepos.
We've found ourselves creating repeated deployment environments just for the sole purpose of bypassing the approval process - we should have the ability to override that from workflows, e.g:

environment: staging
  approval: true/false

And this is not exactly related to the issue that was initially presented here, but the UI should automatically filter out deployment environments that you're not able to approve - it's such a small quality of life change that will be super helpful for big matrices that require deployment environments.

[chrisponton]

Come on GitHub, whats going on? Just copy the idea/design from GitLab? Or the simple idea suggested from the comments:

environment:
   deployment: false

Thats a none breaking change and an if statement check around the deployment functionality:

if (envirionment != null && deployment == true)

There you go I've written it for you... not much to do now 😉

I am sure several of us will fix it for free if its a priortity or a budget issue....

[nebuk89]

Sorry for being quiet on this one, it is on our list still and we are seeing if it's something we can get to in the next few months <3

[ilmax]

Holy moly, I thought this day would never come... just today I was re-checking the status of this one!

[cnnranderson]

@spaceemotion

It appears it's just been formally tied to the roadmap now. The issue is still "open" and marked in the Q2 April-June release window. (unless I'm misunderstanding it). We're close but still have to wait a little bit longer.

[jarpoole]

This is awesome!

[dumptruckman]

Hallelujah!

[nebuk89]

at least it wasn't a picture of me that @ilmax had the stick poking 😆

Sorry yeah we are on track to do this before end of March (a little ahead of plan as we shuffled stuff). I should have updated here but really if something has >100 up votes in the community and 'we are committing to a date' I am going to get it added to our roadmap going forward.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[SyedShaheerHussain]

no — not today. In GitHub Actions, environment-scoped secrets are inseparably tied to deployments.

[salmanmkc]

This is now available. Hope you enjoy! It was fun to work on this feature for you all.

Use deployment: false

jobs:
  test:
    runs-on: ubuntu-latest
    environment:
      name: staging
      deployment: false
    steps:
      - run: echo "Staging secrets accessible, no deployment created"
        env:
          API_KEY: ${{ secrets.API_KEY }}

What's not compatible: custom deployment protection rule apps (job will fail — remove deployment: false or the custom rule).

Docs:

• Using environments without deployments
• Deploying to an environment
• Custom deployment protection rules
• Changelog

[salmanmkc]

is it just me or even with deployment: false it is still asks for authorization in case of branch protection rule? This limits situation where you want to run terraform plan without any deployment -> manual approval gate for apply with deployment: true

My previous response to a similar question here here:

But essentially that would mean we suddenly allow everyone to bypass branch protection rules by adding deployment: false, it could be a big security issue, secrets could be accessed that easily, without needing approvers just because someone decided to add deployment: false. The only safe way to do it is to enforce existing branch protection rules, or to deny those from working entirely similar to how custom app deployment protection rules + deployment: false works at the moment.

[bruce-szalwinski-he]

yup, waited years for this, and it turns out, I'm still waiting. This doesn't help me at all.

[luisdibdin]

is it just me or even with deployment: false it is still asks for authorization in case of branch protection rule? This limits situation where you want to run terraform plan without any deployment -> manual approval gate for apply with deployment: true

My previous response to a similar question here here:

But essentially that would mean we suddenly allow everyone to bypass branch protection rules by adding deployment: false, it could be a big security issue, secrets could be accessed that easily, without needing approvers just because someone decided to add deployment: false. The only safe way to do it is to enforce existing branch protection rules, or to deny those from working entirely similar to how custom app deployment protection rules + deployment: false works at the moment.

I think you may be able to work around this by restricting who can assume your deployment roles to only be able to be assumed from the main branch. Then have .GitHub/ folder protected by CODEOWNERS so people couldn't mess around it with it. But it feels like a bit of minefield to think about to be honest to ensure it's secure. I think best bet is to create two environments and use one for terraform apply, one for plan with deployments set to false. Duplicates the secrets but it's the better than nothing.

[alekc]

or we could simply have a possibility of setting up manual step (without the enterprise gate keeping) like it was asked over and over. Imho as it is, github actions are not usable for anything more complex than a simple package release/testing.

[christhebatchelor]

is it just me or even with deployment: false it is still asks for authorization in case of branch protection rule? This limits situation where you want to run terraform plan without any deployment -> manual approval gate for apply with deployment: true

My previous response to a similar question here here:

But essentially that would mean we suddenly allow everyone to bypass branch protection rules by adding deployment: false, it could be a big security issue, secrets could be accessed that easily, without needing approvers just because someone decided to add deployment: false. The only safe way to do it is to enforce existing branch protection rules, or to deny those from working entirely similar to how custom app deployment protection rules + deployment: false works at the moment.

Azure Devops already allows this functionality via libraries. You just have to entitle a new pipeline access before the first run. After that you can run the pipeline over and over with no additional approval gates unless configured elsewhere.