azure-cli: az functionapp create is not idempotent
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
- Create functionapp with cli.
az functionapp create -g test --consumption-plan-location centralus -n testidempotent -s testidempotent - Deploy to functionpp from package (Visual Studio publish, devops pipelines, cli, kudu, etc)
- Verify functionapp is running.
- Run create again
az functionapp create -g test --consumption-plan-location centralus -n testidempotent -s testidempotent - Verify running functionapp was removed.
Expected 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).
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 4
- Comments: 21 (6 by maintainers)
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.
Running into the same issue using Bicep. Deploying the infra for a function app resource via Bicep blows away the existing functions in the function app, causing downtime until the function app is redeployed to the given resource.
@ankitkumarr do you have more context on this? Is the resource being re-created? Or is the deployment being deleted?