Extend task to support single revision with suffix

[Daniel-Krzyczkowski]

Hi,

It would be great to support scenario, where single revision is used for the Azure Container App. In this case we could specify the "revisionSuffix" together with the image from the Azure Container Registry, here is example:

  - task: AzureContainerApps@0
    displayName: Build and deploy Container App
    inputs:
      connectedServiceNameARM: connection-to-azure
      acrName: 'acrazure'
      containerAppName: 'test-aca'
      imageToBuild: 'mytestacr.azurecr.io/app:latest'
      revisionSuffix: $(Build.BuildId)

This would enable scenario where we can define revision suffix and also indicate which Docker image to use from the container registry.

[cormacpayne]

@Daniel-Krzyczkowski Hey Daniel, apologies for the delayed response -- this is an interesting feature request because it's currently exposed in our task via the properties.template.revisionSuffix field that can be provided with the YAML configuration file passed to the yamlConfigPath argument; however, this does seem like a scenario that we could set a default value for (e.g., $(Build.BuildId)) and allow it to be configurable via an argument to the task.

For context: one of the reasons that we introduced the yamlConfigPath argument was to not only allow users to define all aspects of their Container Apps deployment with a single file, but also reduce the need for us to expose every current and future property that can be provided as an argument to this task, as it can become pretty cluttered pretty quickly.

Does using this YAML configuration file work for your specific scenario, or is this something that you'd want to use specifically as an argument for the task? Thanks in advance!

[Daniel-Krzyczkowski]

@cormacpayne Hi Cormac, thank you so much for the answer! I was not aware of yamlConfigPathargument. However in such scenario it means that we have to somehow update the revisionSuffix version in the YAML configuration file then. Having some default value as you mentioned, like BuildIdwould be helpful in my opinion so we can cover the scenario where we want to have single revision with different values during each deployment.

[cormacpayne]

@Daniel-Krzyczkowski Hey Daniel, thanks for your reply -- I agree with your sentiment, there would be additional work required within the Azure Pipelines to propagate the value of the BuildId to the YAML configuration file that you'd need to add and it could be worth just having a default value for the revisions that are then configurable from a task argument. Let me discuss this proposal with folks on the team and I'll keep this issue updated with anything additional we may have. Thanks!

[Daniel-Krzyczkowski]

@cormacpayne Great, thank you so much, Cormac!