azd provision in Azure Pipeline not detecting existing service

[johnnyreilly]

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

Output from azd version
Run azd version and copy and paste the output here:
1.11.0

Describe the bug

I'm not sure if this is a regression, or if this never actually worked and I deceived myself that it did.

Upon reflection, our usage of a default value for SERVICE_WEB_RESOURCE_EXISTS has perhaps served us poorly - it means we're not aware if behaviour changes.

// azd will provide the following parameters
param containerAppExists = bool(readEnvironmentVariable('SERVICE_WEB_RESOURCE_EXISTS', 'false'))

In this blog post I explain how to use AZD to speed up incremental deployments of container apps in Azure Pipelines: https://johnnyreilly.com/using-azd-for-faster-incremental-azure-container-app-deployments-in-azure-devops

However, part of the mechanism describes the "magic" environment variables provided by azd provision. These are variables like SERVICE_WEB_RESOURCE_EXISTS and the mechanism for providing them can be found here:

azure-dev/cli/azd/pkg/project/service_target_containerapp.go

Lines 174 to 190 in 837d4e8

	func (at *containerAppTarget) addPreProvisionChecks(ctx context.Context, serviceConfig *ServiceConfig) error {
	// Attempt to retrieve the target resource for the current service
	// This allows the resource deployment to detect whether or not to pull existing container image during
	// provision operation to avoid resetting the container app back to a default image
	return serviceConfig.Project.AddHandler("preprovision", func(ctx context.Context, args ProjectLifecycleEventArgs) error {
	exists := false
	// Check if the target resource already exists
	targetResource, err := at.resourceManager.GetTargetResource(ctx, at.env.GetSubscriptionId(), serviceConfig)
	if targetResource != nil && err == nil {
	exists = true
	}
	at.env.SetServiceProperty(serviceConfig.Name, "RESOURCE_EXISTS", strconv.FormatBool(exists))
	return at.envManager.Save(ctx, at.env)
	})
	}

However, regardless of the existence of a container app, AZD is reliably providing false where it should be providing true when a service exists

To Reproduce

Follow the steps in this blog post: https://johnnyreilly.com/using-azd-for-faster-incremental-azure-container-app-deployments-in-azure-devops

After the initial deployment, log into the portal to look at the root deployment created by azd. Look at the inputs and you should see a SERVICE_WEB_RESOURCE_EXISTS that is reliably false

Expected behavior

After the initial deployment, log into the portal to look at the root deployment created by azd. Look at the inputs and you should see a SERVICE_WEB_RESOURCE_EXISTS that is reliably true once the service exists.

Environment
Azure Pipelines

Additional context
The blog post linked covers a good amount of this context

It's possible to work around this issue by creating the variable by hand - here's an example:

- 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: |
          if az containerapp show --name "$(zgptZebraGptContainerApps)" --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

- task: AzureCLI@2
  displayName: Provision Infra
  inputs:
      azureSubscription: ${{ variables.serviceConnection }}
      scriptType: bash
      scriptLocation: inlineScript
      ${{ if eq(parameters.forceDeployInfra, true) }}:
          inlineScript: azd provision --no-prompt --no-state
      ${{ else }}:
          inlineScript: azd provision --no-prompt
  env:
# ....
    SERVICE_APP_RESOURCE_EXISTS: $(SERVICE_APP_RESOURCE_EXISTS)

It feels wrong that we should be doing this though.

[v-xuto]

We are following up on this issue. cc @rajeshkamal5050

[johnnyreilly]

Possibly linked to #4402 ?