Describe the bug
The az functionapp create command is not idempotent, which breaks the guidelines. If there is a function app running from package, running az functionapp create removes the deployed package (or at least the mechanism that wires the deployed package to the app).
To Reproduce
az functionapp create -g test --consumption-plan-location centralus -n testidempotent -s testidempotentaz functionapp create -g test --consumption-plan-location centralus -n testidempotent -s testidempotentExpected behavior
CLI has clear idempotent guidelines. Running this command twice should not remove/delete a running functionapp deployment.
Additional context
My contextual scenario, which is a common goal of the industry, is an idempotent CI/CD deployment pipeline that deploys infra & software in a single pipeline (deploying software to a known, declarative environment that sets itself to known state as part of deploy). As such, the pipeline would run the az functionapp create command before deploying the new function app build. Because of this bug, there is a window of down time between when the az functionapp create command completes and when the function app is built, tested, and deployed (can be minutes, hours, days if the deployment fails).
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @ahmedelnably, @fabiocav
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @ahmedelnably, @fabiocav
We're impacted by this as well.
@ankitkumarr do you have more context on this? Is the resource being re-created? Or is the deployment being deleted?
Any update or feedback on this? @fabiocav or @ankitkumarr ? Would really love to get this fixed. Happy to help out in any way I can -- examples, repro, PR, etc.
We are experiencing somewhat the same issue: we have a functionapp (Node.js) deployed as package through func, and our build pipeline provisions the Azure resources using the CLI under the assumption that it's idempotent.
As soon as the az functionapp create command is run, all functions in the app lose their contents and the app settings are reset to their defaults.
I'm having the same experience as @sanderploegsma describes. Only difference is that my pipeline deploys a functionapp using the dotnet runtime, but the result is the same: contents are lost and default app settings are reset to their default value and custom app settings are removed completely.
Currently solved this using an az resource show to check in my infrastructure that the function app already exists to skip the az functionapp create step. But this is not ideal and inconsistent with the creation of the remaining azure infrastructure.
Any update on this?
Hi, apologies for the delay! I must have missed notifications on this one.
As pointed out, the issue is that at every create call, the az functionapp create command creates a payload to create a new site with empty-ish "App Settings" config. This likely updates the already existing function app, and wipes out Application Settings. Deployments often depend on Application Settings such as WEBSITE_RUN_FROM_PACKAGE, and having those wiped out, can affect your function app.
@anthonychu and @fabiocav, flagging this for discussing the correct approach / priority.
@ankitkumarr -- any traction on this one?
Hi @ankitkumarr @anthonychu @fabiocav -- any updates here?
Most helpful comment
Hi, apologies for the delay! I must have missed notifications on this one.
As pointed out, the issue is that at every create call, the
az functionapp createcommand creates a payload to create a new site with empty-ish "App Settings" config. This likely updates the already existing function app, and wipes out Application Settings. Deployments often depend on Application Settings such asWEBSITE_RUN_FROM_PACKAGE, and having those wiped out, can affect your function app.@anthonychu and @fabiocav, flagging this for discussing the correct approach / priority.