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

[Ian1971]

We've got around this by having 1 PR environment. Might not work for everyone, but fits our use and stops us getting an environment for each PR branch.

e.g.
environment: ${{ github.event_name == 'pull_request' && 'PR' || needs.<job>.outputs.branch_name }}

[hikerspath]

Would not work for us because we have secrets based on the environments and it still wouldn't prevent the act of it being referred to as a deployment which is really where the issue comes into play. Need to separate environments from deployments as these track differently in things like Jira and MS DevOps.

[hikerspath]

Functionally, environments should not equal a deployment. These trigger different resultant code to tools like MS DevOps, Jira, and others that track deployment events. It is functionally possible to require environment-based secrets but perform something like a terraform plan or other test suite which is not performing any action itself. I agree that there should be an override option of deployment: false or some sort of thing.

[octatau]

+1 deployment: false will be very helpful

[hluaces]

Everybody is saying the same things. Can we please agree to use a 👍 reaction so that everybody that is subscribed doesn't receive a constant barrage of replies that don't really add much to the discussion?

[yuvmen]

I think you are right, writing a reply adds nothing, we should indeed use the 👍 reaction instead

[hluaces]

T-t-thanks 👍

[thomas-ej-worm]

I don't see any problem in replies. Traffic on this issue will help that GitHub gets aware of it.

If you don't want to get mails on replies, use this button:

[j616]

Discussions are ranked based on up-votes, not comments. At least they are on the Discussions page.

[joelcoxokc]

Hello... Any updates on this.. We spent a lot of time moving everything over to environments using git actions.. And now we have this massive mess with 15 deployment events being created from one deployment...

We need the environment secrets in each of 15 different dependency actions...

But now we have 15 staging/production deployments... when it should only be one..

This should only be triggered after our final run. Please Please help!

I need to be able to specify in the first 14 actions to not create a deployment...

deployment: false

If one of these actions fail... we don't want Jira and other devops tools being notified that a deployment went through.

[zhangtbj]

Interesting..... This problem confuse people almost 2 years, but still no fix from Github...

I just need a variable from different env group, I don't want any deployment...

But now it still makes us crazy every day:

[dannywebster]

Maybe this can help if it's a variable (and not a secret) you need:

https://github.com/orgs/community/discussions/36919#discussioncomment-10048743

[YuvalGlizerin]

+1

[anthansson]

+1

[anthansson]

Why the thumbs down? 🤨

[dunklesToast]

Cause +1 doesn't help the discussion. Just add a 👍🏻 reaction or upvote to the original post.

[anthansson]

Was thinking that might be it, thanks!

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

[im-divyanshu]

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.