az webapp config set --linux-fx-version always deploys "PHP version : 8.0.30" and not the specified linux-fx-version

[zockette]

Describe the bug

When trying to change the stack (full switch like java => python or just version change python 3.12 => 3.8) with:
az webapp config set --name APP_NAME --slot SLOT_NAME --resource-group RG_NAME --subscription SUB_NAME --linux-fx-version "LINUX_FX_VERSION", the deployed container always ends-up being a PHP container ("PHP version : 8.0.30").

Related command

az webapp config set --name APP_NAME --slot SLOT_NAME --resource-group RG_NAME --subscription SUB_NAME --linux-fx-version "LINUX_FX_VERSION"

Errors

Deploying anything else than a PHP linux-version still deploys a PHP container.

az webapp config set --name APP_NAME --slot SLOT_NAME --resource-group RG_NAME --subscription SUB_NAME --linux-fx-version "PYTHON|3.12"
az webapp config set --name APP_NAME --slot SLOT_NAME --resource-group RG_NAME --subscription SUB_NAME --linux-fx-version "PYTHON:3.12"
az webapp config set --name APP_NAME --slot SLOT_NAME --resource-group RG_NAME --subscription SUB_NAME --linux-fx-version "NODE|18-lts"
az webapp config set --name APP_NAME --slot SLOT_NAME --resource-group RG_NAME --subscription SUB_NAME --linux-fx-version "NODE:18-lts"

They all cause this:

Issue script & Debug output

Pick a linux-fx-version from: az webapp list-runtimes --os-type linux (which seems to give outdated values by the way since JAVA 21is not listed there but can be picked from the Azure Portal).
Run: az webapp config set --name APP_NAME --slot SLOT_NAME --resource-group RG_NAME --subscription SUB_NAME --linux-fx-version "PYTHON:3.12"
Ssh to App Service Container and check what the deployed container is from the welcome message.

Expected behavior

Setting --linux-fx-version as a value from az webapp list-runtimes --os-type linux in az webapp config set should have the right container deployed.

Environment Summary

az --version
azure-cli 2.54.0
core 2.54.0
telemetry 1.1.0
Extensions:
bastion 0.3.0
Dependencies:
msal 1.24.0b2
azure-mgmt-resource 23.1.0b2

Additional context

I tried using the values from function apps as well as linux-fx-version, it doesn't work either (az functionapp list-runtimes --os linux --query "[].{stack:join(' ', [runtime, version]), LinuxFxVersion:linux_fx_version, SupportedFunctionsVersions:to_string(supported_functions_versions[])}" --output table, coming from https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings#linuxfxversion.
I also tried fiddling around with --python-version but it seems to have no effect.

[azure-client-tools-bot-prd]

Hi @zockette,

2.54.0 is not the latest Azure CLI(2.58.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @AzureAppServiceCLI, @antcp.

[Arthusmeng]

Yes, i have the same issues.
I think this is App service frame issues. maybe you container is running.
you can see it when you in azure resource explorer. Go to app service resource ,maybe see some run-time os have.
like this

Az cli have not command az webapp config delete only have az webapp config set --windows-fx-version.
I find fix it only using ARM . i hope microsoft add new command to fix it easy.

[seligj95]

Investigated what's going on here and the issue is the formatting when you input a value into the --linux-fx-version parameter. That site property can be interpreted as a free-text field, and if you don't input the value exactly as the platform needs it to be, you will get defaulted to whatever the current PHP version is. One way to see this is to go into the Azure portal and update the stack for the app in the configuration blade to the intended value. When you do that, you can see the format of the input it is looking for when you check what the linuxFxVersion gets set to. I'll have to dig deeper as to why this formatting is different than in other places.

The command does work when you format the input correctly though which means this is not a CLI issue, but rather a backend issue that needs to get addressed there. For that reason, I'm closing this issue but have added this to an internal tool for triage. I will update the parameter description in the meantime to callout this formatting specifically.

[seligj95]

Re-reading your comment, I see you have tried the right format for the value, so not sure why it didn't work. I tried to repro and was able to get it to work by using this like in the below screenshot. Can you update to the latest CLI version and try again?

and got this: