Kudu: Azure GitHub deployment | Remove additional files at destination folder.

Created on 1 Aug 2018  Â·  6Comments  Â·  Source: projectkudu/kudu

Hello Team,

When we use GitHub as a deployment option in Azure web app deployment then it first deploys content to the Repository folder and then deploys to WWWROOT which doesn’t delete the additional content available in the WWWROOT folder.
If I have any additional files under WWWROOT folder which is not the part of GitHub committed deployment then that file will not be deleted.
While in Visual Studio deployment we can “remove additional files at destination” through setting tab.

Below it the GitHub deployment cycle,
https://github.com/projectkudu/kudu/wiki/Deploying-from-GitHub

Is there any option available in GitHub which can delete the additional files available at the destination.

Thanks in advance!

Most helpful comment

Any update on this? It's been 2.5 years.

All 6 comments

Kudu will only delete the files which are part of previous deployment but removed from current one. See https://github.com/projectkudu/KuduSync. Is that you observed? I don't think we have option currently to remove anything not in current deployment. It seems like a good option, IMO.

If you are adventurous and have time, try improving KuduSync (introduce new knob) and send us PR. We can try to integrate and light up end-to-end.

Any update on this? It's been 2.5 years.

I made two deployments using the github action azure/webapps-deploy@v2:

  1. First deployment added a src file: DEPLOYMENT_MARKER
  2. The second deployment added a new src file DEPLOYMENT_MARKER_1, and removed the old DEPLOYMENT_MARKER file

After the second deployment I SSH into our app service files and check /home/sites/wwwroot and this is what I see:

Screenshot 2021-04-09 at 15 20 42

The old files are still there. This means that if you have a bug in an old file that is causing your app to crash on startup and you try to solve the problem by removing the file. The problem will persist. This one issue is basically making Azure App Service unusable in any enterprise or professional capacity.

The team over at webapps-deploy blame this problem on this exact issue: https://github.com/Azure/webapps-deploy/issues/20#issuecomment-737889262

@suwatch will this issue ever be fixed?

Linux or Windows? Assuming this is the test site - provide the sitename, utc times of both deployments.

This is a Linux App Service running Node 12. Is it okay if I email you the details? I am currently also in contact with microsoft support, they suggest setting this option in Kudu: SCM_ZIPDEPLOY_DONOT_PRESERVE_FILETIME=1 is there a way this might solve my problem?

I was able to solve my issue by adding this to my app service configuration: WEBSITE_RUN_FROM_PACKAGE="1" more info can be found on it here: https://docs.microsoft.com/en-us/azure/app-service/deploy-run-package#enable-running-from-package.

Note: this works for me because our app is stateless and does not require writing to files

Was this page helpful?
0 / 5 - 0 ratings