-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
azurerm_linux_function_app
broken if running terraform apply
a second time
#16396
Comments
Hi @sebader can you share with us what the input into var.additional_app_settings is? In general I have the experience with Java that you have to be careful not to set app_settings that conflict with or duplicate the application stack |
Sure, the entire code is here, but the extra App setting is actually only just one more |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Is there an existing issue for this?
Community Note
Terraform Version
1.1.7
AzureRM Provider Version
3.1.0
Affected Resource(s)/Data Source(s)
azurerm_linux_function_app
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Terraform should not break the function
Actual Behaviour
After the first deployment of the Function app, plus the actual Function code, using the Function core tools are complete, it looks like this and all is good:
From the ARM template export:
Next time I run
terraform apply
, the plan wants to (and will) remove the RUN_FROM_PACAKGE app setting.Afterwards, not only is the package setting gone, but also all the app settings regarding the runtime version. Result: Function is not working anymore.
Even after running the Function core tools deployment again (which is successful), the Function is still broken beyond repair.
The sample shows a Node Function, but I have the same behavior on a dotnet6 function
Steps to Reproduce
func azure functionapp publish my-func --build local --javascript
Important Factoids
No response
References
No response
The text was updated successfully, but these errors were encountered: