azure-pipelines-tasks: AzureWebAppContainerV1 incorrectly sets 'windowsFxVersion' for linux container

How can this issue be swept under the carpet? This is clearly blocking deployment of Linux container.

Just FYI, I switched to the AzureRmWebAppDeployment@4 task in DevOps, that does it correctly:

- task: AzureRmWebAppDeployment@4
  displayName: Deploy to Azure
  inputs:
    ConnectionType: 'AzureRM'
    azureSubscription: ${{ parameters.azure_subscription }}
    appType: 'webAppContainer'
    WebAppName: ${{ parameters.app_service_name }}
    DockerNamespace: ${{ parameters.dockerNamespace }}
    DockerRepository: ${{ parameters.dockerRepository }}
    DockerImageTag: ${{ parameters.dockerImageTag }}

Due to inactivity we are closing this. If it is still exists please raise a new bug

I’ve hit this issue recently also. I have some Bicep templates that I am using to deploy App Service resources (and other things) within a pipeline, and do not want to set linuxFxVersion in the Bicep template because I want that to happen later on in the pipeline via the AzureWebAppContainer task.

If I don’t set linuxFxVersion when the App Service is created the AzureWebAppContainer task ends up setting windowsFxVersion i.e. the task output includes: Trying to update App Service Configuration settings. Data: {"appCommandLine":null,"windowsFxVersion":"DOCKER|undefined"}.

As per the issue description, setting a placeholder linuxFxVersion on the App Service does workaround this, but it’s not something I want to maintain.

I have also now switched to use az webapp config container set as per this comment, and that’s setting linuxFxVersion fine and has unblocked me for now.

In case it’s helpful to have an example, I have switched this:

- task: AzureWebAppContainer@1
  displayName: 'Deploy to web app' 
  inputs:
    azureSubscription: '$(ServiceConnection)'
    appName: '$(WebAppName)'
    multicontainerConfigFile: '$(Pipeline.Workspace)/path/to/docker-compose.yml'
    deployToSlotOrASE: true
    resourceGroupName: '$(ResourceGroupName)'
    slotName: '$(WebAppDeploySlotName)' 

To this:

- task: AzureCLI@2
  displayName: 'Deploy to web app'
  inputs:
    azureSubscription: '$(ServiceConnection)'
    scriptType: pscore
    scriptLocation: inlineScript
    inlineScript: |
      az webapp config container set --name "$(WebAppName)" --resource-group "$(ResourceGroupName)" --multicontainer-config-file "$(Pipeline.Workspace)/path/to/docker-compose.yml" --multicontainer-config-type COMPOSE --slot "$(WebAppDeploySlotName)"

@PhilipsonJoseph This issue is still outstanding. As you note above, any ARM template deployed without linuxFxVersion starting DOCKER| strips container from the kind so app,linux,container becomes app,linux. This is easily worked around by not using an exact string match for the OS type lookup, or instead case-insensitively searching “linux” in the kind so that a match occurs when falling back to the supplied kind when the Map misses. I’ll raise a PR.

@nadesu @PhilipsonJoseph @v-nagarajku do you know when we might see a review for this one line correction and an update to the task?

I ask as this is currently blocking my team from being able to use this task as intended, and we will need to make alternative plans if we think this may take some time to make it’s way out.

Thank you.

I still have this issue when using AzureRmWebAppDeployment@4.

When I update the Tag of a container which runs as “app,linux,container”, the AzureRmWebAppDeployment@4 process updates the “LinuxFxVersion”. But when I open the container settings in Azure Portal, it seems that the container runs the “WindowsFxVersion” which isn’t updated.

As a workaround, I now also explicitly set the “SiteConfig” Properties when running the AzureRmWebAppDeployment@4. And this works. When updating the tag of a container, it now downloads this correct version when starting the container.

This is my Task now:

            - task: AzureRmWebAppDeployment@4
              displayName: 'Deploy xxx Container ${{ parameters.environmentName }}'
              inputs:
                ConnectionType: 'AzureRM'
                azureSubscription: ${{ parameters.serviceConnectionName }}
                appType: 'webAppContainer'
                WebAppName:  ${{ parameters.appName }} 
                DockerNamespace: ${{ parameters.containerRegistry }}
                DockerRepository: ${{ parameters.imageRepository }}
                DockerImageTag: ${{ parameters.tag }}
                ConfigurationSettings: -linuxFxVersion "DOCKER|${{ parameters.containerRegistry }}/${{ parameters.imageRepository }}:${{ parameters.tag }}" -windowsFxVersion "DOCKER|${{ parameters.containerRegistry }}/${{ parameters.imageRepository }}:${{ parameters.tag }}"

I just spent an hour debugging this as well. The kind was set to app,linux and that seemingly caused the image to be written to WindowsFxVersion

I used the Azure CLI to set the LinuxFxVersion, which then updated the kind to app,linux,container, but the deployment task keeps updating the WindowsFxVersion, maybe because that setting is still populated as well?

Is there a way to reset the WindowsFxVersion?

We’ve also just hit this after spending the afternoon trying to work out why our DevOps deployed image wasn’t working. Same issue.