Ability to rename an environment

[greggbjensen]

Select Topic Area

Product Feedback

Body

We have many secrets set up in our environments, and unfortunately, the initial ones we created start with an uppercase letter. Now we have standardized on all lowercase letters to make common actions easier. However, we cannot rename an existing environment, clone it, or copy the secrets.

It would be great if we could rename an environment to fix this.

[christophercouch]

Hi @greggbjensen,

I see the challenge you're facing. Having the ability to rename an environment, especially when you're standardizing naming conventions, would indeed be a helpful feature. This would also simplify the process of managing secrets and environments without having to recreate everything from scratch.

I'd recommend submitting this as a feature request directly through the GitHub feedback form. This ensures the GitHub team can evaluate your suggestion.

Thanks for sharing your feedback!

[thunermay]

+3 (3 developers): initialized as "production" and have to rename it for the sake of terraform to "prod"

[vuolo]

+2

[ilchenkoArtem]

+1

[greggbjensen]

Thanks for the reply!

[Arno-ATU]

+1 any updates on this?

[nebuk89]

This is a good idea, I will add it to our paper cuts list to try to get to. We are getting pretty full for this year (we have a bunch of paper cuts :D ) but I will ensure this is in the list and considered <3

[nebuk89]

I would <3 y'alls thoughts on how this should interact with the fact that if a workflow references an environment that doesn't exist. Github Actions creates it. I guess my worry here is that files being missed in rename would just 'create' new environments.

Or should we just block this behavior 👀
https://github.com/orgs/community/discussions/84203

[cmyers009]

I would <3 y'alls thoughts on how this should interact with the fact that if a workflow references an environment that doesn't exist. Github Actions creates it. I guess my worry here is that files being missed in rename would just 'create' new environments.

Or should we just block this behavior 👀 https://github.com/orgs/community/discussions/84203

I am thinking that if the environment does not exist and is being referenced, it should throw either a warning or an error, because I am not sure what the point of creating a new, empty environment would be.

it seems like the behavior as you describe makes the potential issue (incorrectly named environments) harder to find than if it failed in build step.

This next part may be out of scope, but I think it would be a really cool idea if GitHub could detect recently changed environment names, and then give a warning on the screen like “You recently changed the environment name for previous_environment to new_envirnment. You are still referencing the old environment name. {list of links to take you to that location in your workflow file}
with an option to dismiss so you don’t get notified of the issue again.

[iCount]

This is so good idea

[donnaken15]

I'm wondering about this too because I'm trying to test actions and deployments are getting labelled as the environments I made, which I named without thinking they would be used for that

[t9luke]

Apologies for the bump, but are there any updates? I have one environment where the name no longer makes sense for its current use. I’d recreate it, but since I don’t have access to the original secrets, being able to rename it would be a huge help.

[tonytromp02]

Yes, also wanted this to be as simple as edit name. But seems AI features have become more important than basic requests :(

[aguerrerott]

Still no updates 💔🥀