v3 deployment does not work with clean:false

[DavidBoike]

We had a deployment that worked great with v2:

      - name: Deploy to Azure
        uses: azure/webapps-deploy@v2
        with:
          app-name: psw-docs
          slot-name: test
          publish-profile: ${{ secrets.AZURE_TEST_PUBLISH_PROFILE }}
          package: output/site

We attempted to update to v3, and while it deployed with the same configuration, it took the site offline during the deploy. That didn't happen before and we don't want it to happen now. So we amended the configuration to include clean: false.

      - name: Deploy to Azure
        uses: azure/webapps-deploy@v3
        with:
          app-name: psw-docs
          slot-name: test
          publish-profile: ${{ secrets.AZURE_TEST_PUBLISH_PROFILE }}
          package: output/site
          clean: false

By the way, it would be great to document those options in the README, not just in the v3 release. In fact, all the examples in the README still use v2.

Then the deployment fails. Here is the output in GitHub Actions:

2023-12-20T18:30:07.7705354Z ##[group]Run azure/webapps-deploy@v3
2023-12-20T18:30:07.7706038Z with:
2023-12-20T18:30:07.7706490Z   app-name: psw-docs
2023-12-20T18:30:07.7707042Z   slot-name: test
2023-12-20T18:30:07.7718959Z   publish-profile: ***
2023-12-20T18:30:07.7719544Z   package: output/site
2023-12-20T18:30:07.7720199Z   clean: false
2023-12-20T18:30:07.7720629Z env:
2023-12-20T18:30:07.7720995Z   DOTNET_NOLOGO: true
2023-12-20T18:30:07.7721553Z   DOTNET_ROOT: C:\Program Files\dotnet
2023-12-20T18:30:07.7722292Z   MinVerVersion: 6.0.2-alpha.0.6
2023-12-20T18:30:07.7722863Z   MinVerMajor: 6
2023-12-20T18:30:07.7723321Z   MinVerMinor: 0
2023-12-20T18:30:07.7723721Z   MinVerPatch: 2
2023-12-20T18:30:07.7724226Z   MinVerPreRelease: alpha.0.6
2023-12-20T18:30:07.7724787Z   MinVerBuildMetadata: 
2023-12-20T18:30:07.7725356Z ##[endgroup]
2023-12-20T18:30:14.1926100Z Package deployment using OneDeploy initiated.
2023-12-20T18:30:21.0489131Z {
2023-12-20T18:30:21.0490294Z   id: 'e8495a528dc742a78ee27b782f9b0ceb',
2023-12-20T18:30:21.0491113Z   status: 3,
2023-12-20T18:30:21.0491802Z   status_text: '',
2023-12-20T18:30:21.0492401Z   author_email: 'N/A',
2023-12-20T18:30:21.0493165Z   author: 'N/A',
2023-12-20T18:30:21.0494146Z   deployer: 'OneDeploy',
2023-12-20T18:30:21.0494846Z   message: 'OneDeploy',
2023-12-20T18:30:21.0495461Z   progress: '',
2023-12-20T18:30:21.0496149Z   received_time: '2023-12-20T18:30:16.7194795Z',
2023-12-20T18:30:21.0497846Z   start_time: '2023-12-20T18:30:16.8288513Z',
2023-12-20T18:30:21.0499008Z   end_time: '2023-12-20T18:30:17.0475987Z',
2023-12-20T18:30:21.0500132Z   last_success_end_time: null,
2023-12-20T18:30:21.0500799Z   complete: true,
2023-12-20T18:30:21.0501307Z   active: false,
2023-12-20T18:30:21.0501796Z   is_temp: false,
2023-12-20T18:30:21.0502301Z   is_readonly: true,
2023-12-20T18:30:21.0510369Z   url: 'https://psw-docs-test.scm.azurewebsites.net/api/deployments/latest',
2023-12-20T18:30:21.0511920Z   log_url: 'https://psw-docs-test.scm.azurewebsites.net/api/deployments/latest/log',
2023-12-20T18:30:21.0513016Z   site_name: 'psw-docs',
2023-12-20T18:30:21.0513690Z   provisioningState: 'Failed'
2023-12-20T18:30:21.0514710Z }
2023-12-20T18:30:21.2240281Z Updating submodules.
2023-12-20T18:30:21.2241898Z Preparing deployment for commit id 'e8495a528d'.
2023-12-20T18:30:21.2242773Z Running build. Project type: OneDeploy
2023-12-20T18:30:21.2243450Z Copying the manifest
2023-12-20T18:30:21.2244114Z Incrementally deploying to C:\home\site\wwwroot
2023-12-20T18:30:21.2244872Z Deployment Failed.
2023-12-20T18:30:21.2290355Z ##[error]Failed to deploy web package to App Service.
2023-12-20T18:30:21.2306544Z ##[error]Deployment Failed, Package deployment using ZIP Deploy failed. Refer logs for more details.
2023-12-20T18:30:21.2309806Z App Service Application URL: http://psw-docs-test.azurewebsites.net

It says "Refer logs for more details", but here is the JSON from the kudu logs, which is … less than helpful:

[
  {
    "log_time": "2023-12-20T18:30:16.7663452Z",
    "id": "2c2e9f7b-fdd2-4c86-b81e-97d317d7f68e",
    "message": "Updating submodules.",
    "type": 0,
    "details_url": null
  },
  {
    "log_time": "2023-12-20T18:30:16.8132222Z",
    "id": "7ecde5eb-5d91-427c-bc6c-de2c3ce67eaa",
    "message": "Preparing deployment for commit id 'e8495a528d'.",
    "type": 0,
    "details_url": null
  },
  {
    "log_time": "2023-12-20T18:30:16.8913471Z",
    "id": "eac1d918-d3cf-4f5b-8ad7-f134361236ce",
    "message": "Running build. Project type: OneDeploy",
    "type": 0,
    "details_url": null
  },
  {
    "log_time": "2023-12-20T18:30:16.9225971Z",
    "id": "769e6e9a-00af-4f3d-b3a2-8f89ca827e73",
    "message": "Copying the manifest",
    "type": 0,
    "details_url": null
  },
  {
    "log_time": "2023-12-20T18:30:17.0007244Z",
    "id": "7bc57f67-304d-47ec-9af7-e8f05e596dc9",
    "message": "Incrementally deploying to C:\\home\\site\\wwwroot",
    "type": 0,
    "details_url": null
  },
  {
    "log_time": "2023-12-20T18:30:17.1257204Z",
    "id": "ebd7770e-664a-4293-9899-579b1b376b10",
    "message": "Deployment Failed.",
    "type": 0,
    "details_url": null
  }
]

[github-actions]

This issue is idle because it has been open for 14 days with no activity.

[DavidBoike]

Not idle, just holidays. 😄

[github-actions]

This issue is idle because it has been open for 14 days with no activity.

[DavidBoike]

Still valid, please do not close.

[dannysongg]

Hi @DavidBoike,

We should expect some downtime even with v2, as the WebApp needs to be restarted before the changes can take effect. Furthermore, in the case of deploying a ZIP file, v3 behaves very similarly to v2 in that both will unpack and deploy the contents of the ZIP to wwwroot. Can you provide some further details regarding the difference in downtime you observed between v2 and v3.

As for the failed deployment, I took a look at some backend logs and it looks like the deployment ran into a file locking issue which caused the deployment to fail. Here is the error message I found: C:\home\site\wwwroot\CaptureSnippets.dll' because it is being used by another process. Is this a consistently reproduceable issue for you or is it more transient? I would not expect the clean: false to cause this issue so it is curious that the deployment ran as expected without it.

[jasperfirecai2]

I'm having the same issue. All I've done to update is change the uses to be azure/webapps-deploy@v3, and added type: zip and clean: false. Now it doesn't deploy and there's no useful info in logs. It doesn't even deploy with clean: true either.

[dannysongg]

@jasperfirecai2 do you mind sharing the name of the webapp you are trying to deploy to?

[jasperfirecai2]

@jasperfirecai2 do you mind sharing the name of the webapp you are trying to deploy to?

Unfortunately i can't do that due to company NDA.
I got it working by removing the 'type' parameter. somehow deploying using a zip file does work with type is not defined but does not if you set the type to zip

[dannysongg]

@jasperfirecai2 I have seen this behavior in the past when the deployed artifact is packaged as a folder rather than a zip. Can you confirm that your artifact is being packaged as a ZIP and not a folder?

[jasperfirecai2]

the build workflow is as follows

    - name: npm install only prod, build
      run: |
        npm install --omit=dev
        npm run build --if-present
    - name: Archive build from node ${{ inputs.node_version }}
      run: zip -r release.zip node_modules .next next.config.js package.json package-lock.json
    - name: Upload artifact for deploy
      uses: actions/upload-artifact@v4
      with:
        name: ${{ inputs.name }}
        path: <workingdirectory>/release.zip

(dir name is redacted)
And they deployment is

      - name: Download artifact from test job
        uses: actions/download-artifact@v4
        with:
          name: ${{ file-name }}
          path: .
       
      - name: Deploy to main Azure Web App
        id: deploy-to-main-webapp
        uses: azure/webapps-deploy@v3
        with:
          app-name: ${{ app-name }}
          publish-profile: ${{ secret }}
          package: release.zip
          clean: false

if you add type: zip it will fail. This failed for me when i added target-path: /home/site/wwwroot

[dannysongg]

@jasperfirecai2 Without the name of the webapp being deployed to, I do not have much to go off of to investigate. Would you be willing to post the output you get when running the Github Action? You can also share the name of your webapp privately with me by sending me an email to dannysong@microsoft.com

[skaszyca]

Aside from the fact that the deployment doesn't work if the flag is FALSE, has anyone else had the experience of it cleaning the directory if you don't provide a value for the parameter? I would expect that if you don't provide a parameter (since it's optional) that the system would DEFAULT to false, but we have experienced the directory being cleaned when no parameter is provided - whereas V2 did not clean.

[jasperfirecai2]

@dannysongg
It appears i had overlooked a different change i had made to my workflow. that was potentially misconfigured and caused this issue. it was not type: zip that broke it, it was
target-path: /home/site/wwwroot in addition to other parameters. GitHub and Azure both gave no output besides the following on fail:

Cleaning up temp folders from previous zip deployments and extracting pushed zip file /tmp/zipdeploy/f169137c-3fe7-4df5-86a1-7d38da96f561.zip (176.09 MB) to /tmp/zipdeploy/extracted
Error: Failed to deploy web package to App Service.
Error: Deployment Failed, Package deployment using ZIP Deploy failed. Refer logs for more details.

Those 'logs' are nowhere to be found
output from targetpath only