Open christothes opened 1 year ago
AZURE_ENV_NAME is usually expected to be set for system-env.
@ellismg @savannahostrowski , should azd
fail on a call like azd env set AZURE_ENV_NAME foo
??
The error could say something like:
error: AZURE_ENV_NAME can't be manually updated within azd-env.
Or, should azd
use azd env set AZURE_ENV_NAME foo
as an alias for azd env new/select -e foo
and create and/or switch to a new/existing env?
Yeah, AZURE_ENV_NAME
is treated as somewhat special across the implementation of azd
. Allowing this value to change in this way makes me a little scared, I think we would want to do an audit of all the places we use the environment name in azd
today. I am wondering if we should instead expose this gesture as something like azd env rename <old> <new>
Just wondering, @christothes - what's pushing you to do this? As a side note, changing the AZURE_ENV_NAME
may lead to cases where the next provision ends up recreating all of your infrastructure since the AZURE_ENV_NAME is often mixed into the random tag that we generate to append to all resources.
Hi, thanks for creating such an Issue. I am also facing the same issue. As Ellismg mentioned I have a Azure pipeline and it is supposed to do provision for different branches, but it get confuses between the AZURE_ENV_NAME and fails the pipeline as resources are already created.
Output from
azd version
azd version 1.2.0 (commit 99ea7577f0df0df2ba34b677da189fafba18c0f7)Describe the bug Setting the AZURE_ENV_NAME for an environment puts that environment in a bad state where the directory name no longer matches the environment name. This can result in errors like:
"Environment 'newEnvName' does not exist, would you like to create it? (Y/n)"
``To Reproduce
Expected behavior azd should work as expected after setting AZURE_ENV_NAME to a new value