You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@ignacio-valencia Thanks for the feature request. Overall I can see how this feature would add value but I am unsure of how much use it would get. For right I would suggest that this is a good feature to be added through an extension. I am going to leave this issue open and if other community members show interest in this feature we can come back and re-evaluate if it is worth adding it directly to gh.
Reacted by Juan Pablo Martinez and matttford
Reacted by Ignacio Valencia, John McKeever, Filipe Revez, jdschleicher, matttford and Jonny Parry
Reacted by Juan Pablo Martinez, John McKeever, Florent Tatard, Helio Machado, Alex McGonigle, Christian D, Filipe Revez, Christian Berger, Gordon Byers, Sandip Chatterjee and 15 more
The github UI for a workflow lists the workflow runs and shows the environment as the text that is shown. However, using the cli you can't get the environment of the workflow run.
Since that functionality doesn't exist in that way, I would like to list environments and then list workflow runs for a given environment.
I really need this enhancement to set my team's repositories. Github Actions doesn't support organization wide environments like CircleCI contexts or templating repository only create branches and source files not secrets and environments defined in the template. Thus I've been creating my own environment management method with gh cli. gh secret set -e MYENV command omit 404 error if there are no MYENV environment but I expected this command can create new environment if there is no environment named MYENV :(
Reacted by Austin Brown, Peter Hornyack, Julien Bonastre, Max Cascone and Jonny Parry
I would like to see organization level environments that could be applied to multiple repos. In the absence of that, as others above have stated, tooling is needed to manage the environments across many repos.
IMO, The static delay timer on environments is of minimal value in its current form. Setting an "allowed execution time window" would be useful.
Reacted by Roger Noden, Julien Bonastre, Max Cascone and Jonny Parry
I am also looking for this feature. When we setup new repositories, part of the DevOps tasks includes creating the kube config secrets in each environment. This way workflows can only use the credentials in their workflow when the run has been approved, and nobody can arbitrarily switch credentials.
Being able to create the environments would help completely automate this task.
We are breaking the work described in this comment into their own issues so that its easier for folks to contribute. The first of them is below. I'll continue to update this comment as the rest of the issues get written.
Or at least to have an option within the gh env create to not produce an error if the environment already exists, so that repos can have environments and secrets added in an idempotent way
Until this lands in core gh, I wrote an extension that covers it: shbernal/gh-envy.
gh extension install shbernal/gh-envy
gh envy create production --reviewer my-org/ops --wait-timer 30m --branch main --tag 'v*'
gh envy list --json name,reviewers,waitTimer
It does list, view, create, edit, delete and clone, including required reviewers, wait timer, branch and tag policies and custom protection apps. Flags, -R, prompts and --json/--jq/--template follow gh variable and gh secret, so it should be easy to port if the maintainers want any of it upstream.
Activity
samcoe commentedon Feb 3, 2022
@ignacio-valencia Thanks for the feature request. Overall I can see how this feature would add value but I am unsure of how much use it would get. For right I would suggest that this is a good feature to be added through an extension. I am going to leave this issue open and if other community members show interest in this feature we can come back and re-evaluate if it is worth adding it directly to
gh.ignacio-valencia commentedon Feb 4, 2022
hello @samcoe if this functionality takes value away from the command
ref: https://cli.github.com/manual/gh_secret_set
if I can work with environments in other
ghcommands it is illogical that I cannot create an environment withghplease help me!!
DavidGamba commentedon Feb 14, 2022
The github UI for a workflow lists the workflow runs and shows the environment as the text that is shown. However, using the cli you can't get the environment of the workflow run.
Since that functionality doesn't exist in that way, I would like to list environments and then list workflow runs for a given environment.
joosangkim commentedon Mar 16, 2022
I really need this enhancement to set my team's repositories. Github Actions doesn't support organization wide environments like CircleCI contexts or templating repository only create branches and source files not secrets and environments defined in the template. Thus I've been creating my own environment management method with
gh cli.gh secret set -e MYENVcommand omit 404 error if there are no MYENV environment but I expected this command can create new environment if there is no environment named MYENV :(krisrecur commentedon Apr 3, 2022
I would like to see organization level environments that could be applied to multiple repos. In the absence of that, as others above have stated, tooling is needed to manage the environments across many repos.
IMO, The static delay timer on environments is of minimal value in its current form. Setting an "allowed execution time window" would be useful.
matthenry87 commentedon Apr 16, 2022
I am also looking for this feature. When we setup new repositories, part of the DevOps tasks includes creating the kube config secrets in each environment. This way workflows can only use the credentials in their workflow when the run has been approved, and nobody can arbitrarily switch credentials.
Being able to create the environments would help completely automate this task.
johnmckeever commentedon Jul 7, 2022
We would also find this feature VERY valuable!
36 remaining items
gh env list#10502jtmcg commentedon Feb 25, 2025
We are breaking the work described in this comment into their own issues so that its easier for folks to contribute. The first of them is below. I'll continue to update this comment as the rest of the issues get written.
gh env list#10502Hamidsalri commentedon Feb 26, 2025
jparry-tds commentedon Jan 9, 2026
When I try to create a secret in an environment that doesn't exist, it would be useful to optionally be able to create that environment at that point
gh secret set SOME_SECRET --body $someBody --repo org/reponame --env $envName --createenvOr at least to have an option within the
gh env createto not produce an error if the environment already exists, so that repos can have environments and secrets added in an idempotent wayfeat: add gh repo environment list, create, and delete commands
feat: add gh repo environment list, create, and delete (#8)
Upstream sync 2026-05-29 (#16)
Upstream sync 2026-05-29 (#19)
shbernal commentedon Oct 10, 2026
Until this lands in core gh, I wrote an extension that covers it: shbernal/gh-envy.
gh extension install shbernal/gh-envy gh envy create production --reviewer my-org/ops --wait-timer 30m --branch main --tag 'v*' gh envy list --json name,reviewers,waitTimerIt does list, view, create, edit, delete and clone, including required reviewers, wait timer, branch and tag policies and custom protection apps. Flags,
-R, prompts and--json/--jq/--templatefollowgh variableandgh secret, so it should be easy to port if the maintainers want any of it upstream.