azure-pipelines-agent: Agent change (v2.163.1-v2.164.6) causes reconstruction of workspace

Having issue with YAML?

Please log an issue at Azure-Pipelines-YAML. Over there we discuss YAML templates, samples for Azure Pipelines, and designs for upcoming YAML features. Also a place for the community to share best practices, ideas, and so on. File suggestions and issues here if they’re specific to YAML pipelines.

Having issue with Tasks?

Log an issue at Azure-Pipelines-Tasks. It contains all of the in-box tasks we ship with Azure-Pipelines/VSTS/TFS. If you’re having issues with tasks in Build/Release jobs (e.g. unreasonable task failure) please log an issue there.

Having issue with software on Hosted Agent?

Log an issue at Hosted Agent Image Repository. It contains the VM image used in the Azure Pipelines Hosted Agent Pool. If you’re having Build/Release failures that seems like they are related to software installed on the Hosted Agent (e.g. the dotnet SDK is missing or the Azure SDK is not on the latest version) please log an issue there.

Having generic issue with Azure-Pipelines/VSTS/TFS?

Please report it on Developer Community

Have you tried troubleshooting?

Troubleshooting doc

Agent Version and Platform

Version of your agent? 2.164.6

OS of the machine running the agent? Windows/Linux

Azure DevOps Type and Version

dev.azure.com (formerly visualstudio.com) or on-premises TFS/Azure DevOps Server? Azure Pipelines (dev.azure.com)

If on-premises, which release? 2015.0, 2017.1, 2019 RC2, etc.

If dev.azure.com, what is your organization name? https://dev.azure.com/{organization} or https://{organization}.visualstudio.com

https://compnerd.visualstudio.com / https://dev.azure.com/compnerd

What’s not working?

Please include error messages and screenshots.

Something changed between v 2.163.1 and v 2.164.6. The agent has been bumping workspace IDs on each build continuously without cleaning up the previous content. This is leading to constant disk space exhaustion.

Agent and Worker’s Diagnostic Logs

Logs are located in the agent’s _diag folder. The agent logs are prefixed with Agent_ and the worker logs are prefixed with Worker_. All sensitive information should already be masked out, but please double-check before pasting here.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 16 (7 by maintainers)

Most upvoted comments

That’s some great information. That makes perfect sense. We need to be more careful about computing the hash in these types of cases. Thanks for following up and providing the workaround in case others run into this. It will take some time to create and test the solution, so a workaround is definitely a must.