Continuous deployment from GitHub takes nearly 30 minutes

[jhoerr]

I'm deploying an F# function on the consumption plan and am using Paket for dependency management. . Deploying my project from GitHub takes nearly 30 minutes, with package restoration taking about 19 minutes.

I'm not able to run this function locally due to a number of CLI errors that I encounter and have not been able to resolve. As a result I can only use the browser to run/debug the function. As you might imagine this is pretty frustrating.

Repro steps

1. Create a new function app on consumption plan.
2. Clone/deploy https://github.com/jhoerr/iga-tracker-functions.

Expected behavior

The function is deployed reasonably quickly.

Actual behavior

The function is deployed very slowly.

Known workarounds

None.

Related information

Source: https://github.com/jhoerr/iga-tracker-functions

[davidebbo]

Please see https://github.com/projectkudu/kudu/wiki/Isolating-WebJobs-and-Deployment-script-issues for initial steps to isolate.

Is it slow only on initial deployment, and then subsequent ones are faster? I would expect that unless what you're running ignores what's already installed.

[davidebbo]

Fwiw, I just tried deploying your repo, and it took about 7 minutes, so much faster than what you saw. Not sure why the difference.

[davidebbo]

After a no-op change, a subsequent deployment did take 30 minutes, but I think it's caused by the way your script is written. On the second deploy, there in now a packages folder in your repo folder, and the whole thing ends up getting copied to wwwroot, which I assume you don't need.

I think the root of the problem is that you are trying to use a post deploy action instead of taking over the deployment script. That would give you full control over everything that happens.

[jhoerr]

I think the root of the problem is that you are trying to use a post deploy action instead of taking over the deployment script. That would give you full control over everything that happens.

Ahh, OK. I didn't realize the later was an option. I was using some post-deploy Paket restore steps documented here. I'll look to see if this can be done during the deployment rather than after it and go from there.

As an aside, I've noticed that if I run paket restore from the in-browser dev console the folder populates within 1-2 minutes, as opposed to 15-20 minutes with the post-deploy script.

[davidebbo]

To get started scripts (after doing one deployment), go to the Kudu UI and Tools / Download deployment script.

But it's puzzling that it would be faster from command line. My guess is that it's not quite running the same thing. It runs in the same identical sandbox, so everything else being equal, perf should match.

[jhoerr]

I've got the paket restore worked into the build pipeline but I want to double-check that I'm ordering my operations properly. Would it be most appropriate to restore packages into /repository before KUDU_SYNC_CMD, or restore them into /wwwroot after KUDU_SYNC_CMD?

It might be a six/half-dozen situation; I just want to make sure I'm using the deployment script as you've intended.

[lindydonna]

Closing this issue as it appears to be a configuration issue.

@davidebbo could you reply to the question about how to order commands in the deployment script?

[jhoerr]

It's OK with me if you close it. I'll try to repro the problem again on a new app service with the improved build script and will re-open if it persists.