azure-dev icon indicating copy to clipboard operation
azure-dev copied to clipboard

bicep: main.bicepparam environment variables being evaluated too early

Open weikanglim opened this issue 1 year ago • 3 comments

With #4363, we fixed an issue with the main.parameters.json being prompted early in the flow and being cached. This caused environment variables that typically would be evaluated at deployment time, to be evaluated and its results cached early in the process.

The fix did not address the same bug for main.bicepparam. This is due to how main.bicepparam is currently designed -- it is currently cached as part of the result of compileBicepMemoryCache in bicep_provider.go.

We should fix this. Likely, we would need to end up splitting out the compile bicep logic from compile parameters logic. This would introduce a perf hit of a few seconds since we need to invoke bicep build twice -- but still worth separating for correctness and completeness.

weikanglim avatar Oct 03 '24 17:10 weikanglim

FYI @vhvb1989 we had chatted briefly about this a few weeks ago, but just bringing this up to your attention in case you have any thoughts on a better approach here before we start implementation work.

weikanglim avatar Oct 03 '24 17:10 weikanglim

AZD doesn't support prompting for bicepparam. I don't think we need to change it, right?

vhvb1989 avatar Oct 03 '24 17:10 vhvb1989

@vhvb1989 bicepparam reads from environment variables. They can still be set by hooks and evaluated too early.

weikanglim avatar Oct 03 '24 17:10 weikanglim

In the usage scenario in https://github.com/Azure/azure-dev/issues/4593, the main.bicepparam environment variables being evaluated too early will cause the input parameters during deployment to be inconsistent with the actual environment.

Menghua1 avatar Dec 04 '24 09:12 Menghua1

I've a post which documents how to deploy Azure Container Apps with AZD and bumped on this issue. We've found a way to work around it which I've documented here: https://johnnyreilly.com/using-azd-for-faster-incremental-azure-container-app-deployments-in-azure-devops#workaround-for-service_app_resource_exists-not-being-supplied

If you want to drop it into your pipelines right now you could use something like this:

- task: AzureCLI@2
  displayName: Check container app exists # see https://github.com/Azure/azure-dev/issues/4593 for context on why this exists
  inputs:
    azureSubscription: ${{ variables.serviceConnection }}
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: |
      containerAppName="$(containerAppName)"
      resourceGroupName="$(resourceGroupName)"

      if [ -z "$containerAppName" ] || [ -z "$resourceGroupName" ]; then
          echo "SERVICE_APP_RESOURCE_EXISTS: false"
          echo "##vso[task.setvariable variable=SERVICE_APP_RESOURCE_EXISTS]false"
      else
          if az containerapp show --name "$containerAppName" --resource-group "$resourceGroupName" > /dev/null 2>&1; then
              echo "SERVICE_APP_RESOURCE_EXISTS: true"
              echo "##vso[task.setvariable variable=SERVICE_APP_RESOURCE_EXISTS]true"
          else
              echo "SERVICE_APP_RESOURCE_EXISTS: false"
              echo "##vso[task.setvariable variable=SERVICE_APP_RESOURCE_EXISTS]false"
          fi
      fi

johnnyreilly avatar Dec 04 '24 15:12 johnnyreilly