Deploying to a Container Apps: Allow Updating Existing Deployments and Existing Container Registry

[thern743]

The extension currently detects a Dockerfile and allows the user to choose an image-based deployment. However, the extension currently creates a new container registry for each deployment. There doesn't appear to be a way to "update" an existing deployment by publishing an new image/container instance. The evidence here is that the user is never prompted to even select a container registry instance, image name, or tag.

[nturinski]

Thanks for filing this issue. The feature exists in the actual Container Apps extension, so we need to improve the Container App API call to leverage the settings that are created on deploy to container app.

[MicroFish91]

Potentially two options here.

(These solutions assume steps for re-deploying to a containerized app are roughly equivalent to re-deploying to a container app. If this assumption ends up being wrong, we'll need to come up with different set of options.)

Option 1:

There is a good chance Container Apps extension API (v1.0.0) can handle this if we leverage the existing flag for saving user deployment settings since re-deploying from saved workspace settings is already well supported.

There will most likely need to be updates to the Azure Functions extension side of things because the final step of creating the containerized app is handled by the Functions extension, and thus that information will be missing from the deployment settings that could be generated by ACA.

Option 2:

If we don't like the idea of relying on re-deploying through saved workspace settings, we may want to instead update the Container Apps API to be able to pass in existing resources directly. This option will be more expensive, but could give us a less opinionated re-deployment option.