SERVICE_XXX_RESOURCE_EXISTS environment variables are always false when passed as ARM Deployment params in CI environment

[MarcelMichau]

• Make sure you've installed the latest version using instructions in the wiki

Output from azd version
azd version 1.10.1 (commit 31409a3)

Describe the bug
In a CI environment where the SERVICE_XXX_RESOURCE_EXISTS environment variables do not pre-exist in the .azure/<environmentName>/.env file, when running azd provision, the SERVICE_XXX_RESOURCE_EXISTS environment variables are always false when passed as Bicep params.

To Reproduce

1. Run azd init --template Azure-Samples/todo-python-mongo-aca
2. Run azd provision & wait for resources to finish provisioning
3. Open the .azure/<environmentName>/.env file & delete all environment variables except for AZURE_ENV_NAME, AZURE_LOCATION & AZURE_SUBSCRIPTION_ID to mimic the environment variables passed to the CI task.
4. Run azd provision --no-state to force an infra deployment
5. When the provision operation starts, observe the values for SERVICE_API_RESOURCE_EXISTS & SERVICE_WEB_RESOURCE_EXISTS in the .azure/<environmentName>/.env file will update to true
6. Inspect the Deployment Inputs in the Azure Portal - the values for the apiAppExists & webAppExists parameters are still false:

7. Subsequently running azd provision --no-state when the SERVICE_XXX_RESOURCE_EXISTS environment variables are present & set to true in the .azure/<environmentName>/.env file will correctly set the Bicep params to true:

Expected behavior
Running azd provision in a CI environment should set SERVICE_XXX_RESOURCE_EXISTS environment variables to true prior to starting the Bicep deployment so that containers do not get swapped out with the mcr.microsoft.com/azuredocs/containerapps-helloworld:latest placeholder image during deployment.

Environment
Information on your environment:
Windows 11 Pro 23H2 - Build 22631.4169

Additional context
N/A

[weikanglim]

This is indeed a bug. A more full description and a tentative plan of reworking how deploy works in this scenario is described fully in #4232. A related issue that container app deployments faces is described in #3116. FYI @wbreza

should set SERVICE_XXX_RESOURCE_EXISTS environment variables to true prior to starting the Bicep deployment

This may be an acceptable short-term fix. If we do such a thing, perhaps we could also avoid setting the output variable entirely and letting azd perform such determination. Thoughts?

[wbreza]

Yes, I have confirmed a bug and believe the root cause here is from adding support of caching of bicep parameters during provider init phase and they don't get re-evaluated at deploy time and the azd environment was mutated between init & deploy.

cc @vhvb1989

[weikanglim]

@wbreza I see, thanks for the investigation. I think I have a change outside of the tree that was addressing #3973 that may address this as well. Let me see if that would work.

[weikanglim]

This should be fixed with #3973 -- it's currently in the latest daily build if anyone wants to give it a try.

[MarcelMichau]

Hi all

I've run through the reproduction steps detailed in the issue with azd version 1.11.0-beta.1-pr.4157496 (commit 300b7b3332d444b10a5cfd40e358bb31ef2c3384) & can confirm that a subsequent deployment does set the exists variables to true as expected.

Thanks so much for getting this fixed!

[microsoft-github-policy-service]

Hi @MarcelMichau. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[weikanglim]

@MarcelMichau Thanks for giving it a try! I'm glad that it helped resolve your issue. The change will go out with the next release.

As a footnote, we are thinking about improving our strategy for container app deployments. If you have any thoughts around this, feel free to leave a note on ##4232.