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

[lucaslacerdacl-o2ebrands]

+1

[dannywebster]

Had the same issue, also in a terraform plan step where I didn't want the "noise" of a deployment.

Solved this with the gh cli for environment variables, but alas the counterpart endpoint for secrets does not reveal their value.. but just putting it here in case it helps in the env vars use case.

1. Get a list of env vars, perhaps with gh, and assume your workflow has, say, a workflow_dispatch where you pass/choose an input called environment_name. Clearly, you'll use this in a loop, but here it is unrolled for brevity:

var_name=$(gh variable list -R ${{ github.repository }} -e ${{ inputs.environment_name }}  --json name --jq '.[].name')

2. Take that var and pass it in to get the value:

var_value=$(gh api  -H "Accept: application/vnd.github+json"  -H "X-GitHub-Api-Version: 2022-11-28" /repos/${{ github.repository }}/environments/${{ inputs.environment_name }}/variables/${var_name} | jq -r '.value')

[piotrekkr]

This works with environment variables but will not work with environment secrets. You cannot fetch secret value through API. Here is docs. Response looks like this:

{
  "name": "MY_SECRET",
  "created_at": "2019-08-10T14:59:22Z",
  "updated_at": "2020-01-10T14:59:22Z"
}

[dannywebster]

Yep, I acknowledge this fact in my reply.

[piotrekkr]

Ah my bad, sorry. Somehow missed it in your reply.

[dumptruckman]

Perhaps a less than ideal option, but one way around the secrets is to store them in the repository and do something like ${{ secrets[format('{0}', env.SECRET_NAME)] }} (where env.SECRET_NAME is the value from this examples var_value.) In this way, you'd store the repository secret name in the environment variable.

Alternately, just store them in the repository in a namespaced manner like Development_SOME_SECRET and access with ${{ secrets[format('{0}{1}', inputs.environment_name, 'SOME_SECRET')] }}.

[qoomon]

@dumptruckman as a slightly more convenient alternative you can use my action https://github.com/qoomon/actions--set-env

[max-lobur]

Jeez can it be just deployment: false please?

[divyanshuio]

Hii can you accept my answer/reply I am trying to get a badge.

[ebndev]

Hi @im-divyanshu,

We made the decision to disable the ability to earn Achievements in our Community in order to discourage users from participating in coordinated or inauthentic activity like rapid questions and answers in order to earn badges. You can learn more about this decision in our announcement post here Achievements will no longer be available in the Community.

Note that GitHub's Acceptable Use Policies prohibits coordinated or inauthentic activity like rapid questions and answers. As a result, we'll be unmarking the answer and locking this post. 

Any future violations may result in a temporary or indefinite block from the Community. Thanks for understanding.

[trallnag]

I wonder if it is better to provide feature requests / feedback via account managers instead of piling on threads like this one here. Kinda feels stupid to beg for QoL improvements when your employer writes checks worth dozens of millions to Microsoft

[smokedlinq]

What a great feature request. It certainly is annoying that all our PRs produce a deployment to production from needing to do a terraform plan. So far this isn't a problem but there is some automation via webhooks happening with our ITSM platform where we will track all Production environment deployments that is forcing us to have to look and exclude deployments initiated from pull requests.

[tonit]

I'd like to have a solution for this, too. I think Gitlab also solves this by allowing jobs to qualify their access to environment-specific secrets documented here: https://docs.gitlab.com/ee/ci/yaml/index.html#environmentaction

environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: access

here the access property allows to qualify what is happening to the environment with this job. (gitlab has abstractions for: start, stop, verify, access and prepare). I think this would do it for github, too.

right?

[luisdibdin]

It would be great if you could also specify whether non deployment environment accessing needs a review or not. For example, when accessing the environment for a terraform plan, deployment could be set to false and no review required to progress the job. Then when running terraform apply, deployment would be true and a review would be required. In lower environments I'd allow the same developer to approve their own plan, but in prod this could be restricted. This would make GH Actions way more useable for terraform CICD.

[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

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