Azure Web Application not updated, action still claims "Success"

[lassevk]

We discovered that our changes were not appearing in our website, an Umbraco 13 website hosted in Azure earlier this week.

To deploy, we used the wizard in Azure to create the yml files in Github to to the build and deployment, and have since changed these slightly to get release build numbers. The actual scripts being run are not touched by us.

This week we experienced that after publishing a release, and waiting for the build+deploy action to complete, our changes were not deployed. The action claimed it was a success, but clearly it wasn't.

After digging, we discovered that kudusync had failed due to a locked file. Just to be clear, this issue is not about the locked file, that was just the underlying cause.

In the logs from the script execution on the host, I can see that:

Error: Failed to change file that is currently being used   
"C:\home\site\wwwroot\umbraco\Logs\UmbracoTraceLog.DW0MDWK0000DQ.20240318.json"  
Failed exitCode=1, command="kudusync" -v 50 -x -f "C:\local\Temp\zipdeploy\extracted" -t "C:\home\site\wwwroot" -n   
"C:\local\Temp\tmp73B5.tmp" -p "C:\local\Temp\tmp73B5.tmp" -i ".git;.hg;.deployment;deploy.cmd"  
An error has occurred during web site deployment.

The last text there, "An error has occurred during web site deployment" comes from the script, which thus seems to have correctly identified that kudusync failed, as it took a branch to display this error based on the errorlevel.

However, the githut action claims that deployment was successful:

Run azure/webapps-deploy@v3
Package deployment using OneDeploy initiated.
{
  id: 'xxxxxxxxxxxxxxxxxxxxxxxx',
  status: 4,
  status_text: '',
  author_email: 'N/A',
  author: 'N/A',
  deployer: 'OneDeploy',
  message: 'OneDeploy',
  progress: '',
  received_time: '2024-03-18T13:54:57.8413124Z',
  start_time: '2024-03-18T13:54:58.060074Z',
  end_time: '2024-03-18T13:55:14.6408492Z',
  last_success_end_time: '2024-03-18T13:55:14.6408492Z',
  complete: true,
  active: true,
  is_temp: false,
  is_readonly: true,
  url: 'https://??.scm.azurewebsites.net/api/deployments/latest',
  log_url: 'https://??.scm.azurewebsites.net/api/deployments/latest/log',
  site_name: '??',
  provisioningState: 'Succeeded'
}
Deploy logs can be viewed at https://??.scm.azurewebsites.net/api/deployments/xxxx/log
Successfully deployed web package to App Service.
App Service Application URL: https://??.azurewebsites.net

This lead to us spending wasteful time trying to identify the issue with our code, trying to see if we messed up testing, or we managed to do merging wrong, or whatnot, instead of looking at the actual problem.

So, exactly how to reproduce, I would imagine that if you were to be able to simulate that kudusync fails, you would have the same issue, as a number of retries we did all have this same error situation, and the same outcome.

We fixed it by shutting down the site completely during deployment, but it would be nice if the github action actually reported deployment failure, when deployment fails.

Attachments (let me know if you want me to dig up more details from whatnot and I'll provide everything I can)

github action output.txt

deployment script log.txt

deploy-logs.json

[lassevk]

Seems the yml file didn't attach, renamed it to txt and attached it here

azure_lkweb-yml.txt

[CarlSargunar]

I had this exact same problem @lassevk

As a quick fix, if you revert to the V2 action, the deployment works successfully

This is the deploy step from our action

  # Deploy to UAT
  - name: Deploy to Azure WebApp
    uses: azure/webapps-deploy@v2
    with:
      app-name: ${{ env.AZURE_WEBAPP_NAME }}
      slot-name: 'prelive'
      publish-profile: ${{ secrets.AZURE_UAT_XXXXXX_PROFILE }}
      package: ${{ github.workspace }}\publish.zip

[CarlSargunar]

We noticed the problem (and it may be an umbraco specific one, or may be one more related to locked files on our side (particularly log files and nucache files)

[lassevk]

We noticed the problem (and it may be an umbraco specific one, or may be one more related to locked files on our side (particularly log files and nucache files)

The locked file is likely an Umbraco specific problem, or at least related to Umbraco, but the overall issue of a failed deployment being shown as successful is troublesome. If we can't trust the deployment action to actually tell us that there is an issue, we're forced to monitoring it every deployment. We'd rather just have to go look at it if it fails.

[lassevk]

I had this exact same problem @lassevk

As a quick fix, if you revert to the V2 action, the deployment works successfully

This is the deploy step from our action

  # Deploy to UAT
  - name: Deploy to Azure WebApp
    uses: azure/webapps-deploy@v2
    with:
      app-name: ${{ env.AZURE_WEBAPP_NAME }}
      slot-name: 'prelive'
      publish-profile: ${{ secrets.AZURE_UAT_XXXXXX_PROFILE }}
      package: ${{ github.workspace }}\publish.zip

I believe we upgraded because we were getting warnings about v2 being deprecated, I will need to confer with my colleague tomorrow if it was this action that we upgraded due to warnings or something else. Maybe I'm mixing actions here.

[CarlSargunar]

the overall issue of a failed deployment being shown as successful is troublesome

This is the same behaviour we were seeing - the action was reporting as successfully deploying, but the logs showed that it had failed because a locked file. Agreed that this is incorrect behaviour

[CarlSargunar]

I believe we upgraded because we were getting warnings about v2 being deprecated

I'd be curious about that - I've not seen or been able to find any detail - perhaps a mod or admin can help?

I also see that v3.0 back in October was released but nothing has been updated since : https://github.com/Azure/webapps-deploy/releases

[Posiden104]

+1 on this. Extremely frustrating trying to figure out why the action reports success, but my changes aren't being applied. It appeared to be the same issue as lassevk, it was trying to modify a log file but couldn't.

I can confirm using v2 did solve the issue for me. It looks to me that v2 doesn't attempt to access or delete the log files

[CarlSargunar]

My concern is that anyone new to this is automatically going to go for the newest version, but that just doesn't work - the bug is repeatable and consistantly failing.