Need cmdlet to do zip deploy of a function app

[Francisco-Gamino]

Need a cmdlet to publish a function app (from Azure Dev Ops)

Scenario: A customer uses Azure PowerShell to publish to their function app in Azure. This cmdlet can be used anywhere where Azure PowerShell is available including from Azure DevOps.

The cmdlet signature would look like this:

Publish-AzFunctionApp -Name <string> -ResourceGroupName<string>  -ArchivePath <string> -RetryCount [-Force] [-AsJob] [-DefaultProfile <IAzureContextContainer>] [-WhatIf] [-Confirm] [<CommonParameters>]

Name is the function app name
ResourceGroupName is the resource group name
ArchivePath is the path to the zip file with the app content
RetryCount is the number of tries to publish the app content
Force is to bypass the confirmation for the app deployment
AsJob the publish command will be run as a Job

The cmdlet will start a zip deploy and we will pull the status of the deployment until it completes. This cmdlet will follow the implementation for ARM deployments defined here: https://github.com/microsoft/azure-pipelines-tasks/blob/f462aeacedf56ceeeacd3d29027471a59573eaee/Tasks/Common/AzureRmDeploy-common/azure-arm-rest/azure-arm-app-service-kudu.ts#L615.

[Francisco-Gamino]

cc: @stefanushinardi @AnatoliB

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

Issue Details

---

Need a cmdlet to publish a function app (from Azure Dev Ops)

Author:	Francisco-Gamino
Assignees:	Francisco-Gamino
Labels:	Functions, Service Attention, feature-request
Milestone:	-

[Kyle-Eskelin]

Hey @Francisco-Gamino, another very useful feature for this new Azure Function cmdlet would be to have retry logic built-in to the cmdlet. Preferably we could specific a "number of retries" parameter to the cmdlet and have it attempt to publish until it reaches a success status code. Currently we have custom retry logic for publishing with the Publish-AzWebApp cmdlet because it usually fails at least once for a couple of our 15 functions that are published in parallel. However this is not ideal as we have to catch all of the different errors that might happen and handle it in PS code. Thank you! 😀

[Francisco-Gamino]

Thanks @Kyle-Eskelin for this great suggestion. I will look into this.

[Kyle-Eskelin]

Hey @Francisco-Gamino,
One more thing I came across implementing the deployment status check workaround for Publish-AzWebApp, was that I also needed to check that the latest deployment "end_time" was after the Publish-AzWebApp execution. I found that in some cases, the execution of that cmdlet would not produce any error but would also not complete successfully and would not show in the the /api/deployments list. So basically when you queried /api/deployments/latest afterward, it could return a "success" status code, but that's because it was only returning the latest/last deployment which could have been days before. Just wanted to bring this up to make sure it was handled in the new function publishing cmdlet.

Here is some powershell pseudocode explaining the logic I used in my workaround:

$SUCCESS = 4
$FAILED = 3
$startTime = [DateTime]::UtcNow

Publish-AzWebApp call

if no powershell errors, query latest deployment status 
	if latest deployment status  -eq $SUCCESS AND latest deployment end_time -gt $startTime
		then deployment was successful

[Francisco-Gamino]

Thanks @Kyle-Eskelin for the additional information. I will make sure we do this check as well.