This is not a problem or bug or issue. It's just something I noticed and want to know more about. I have checked the official documentation and the Web.
I have a self-hosted agent on Azure DevOps. Because of the pipeline development work I'm doing, I usually have a Remote Desktop connection to the VM as well as the usual connection to dev.azure.com through a browser.
While watching the build in dev.azure.com, I have noticed that the agent uses different workspace numbers -- that is, at the beginning the workspace was C:\vsts-agent-win-x64-2.187.2\_work\1, but it has been incrementing the workspace ID. As I bounce around between different pipelines, branches, and repositories, the workspace ID changes, sometimes incrementing and sometimes going back to an old one. It's currently at C:\vsts-agent-win-x64-2.187.2\_work\6.
As I said, this isn't a problem; it's just something I want to understand. I'm not going to run out of disk space, and the agent always knows where it's at. However, since this is a self-hosted agent, and the contents of the mass-storage medium are persistent, I can imagine the number of workspaces increasing without bound -- and I have an aversion to clutter. Should I be doing some housekeeping, on the C:\ drive, manually deleting workspaces that I don't need anymore?
Contents of the C:\ drive are as follows:
C:\vsts-agent-win-x64-2.187.2\_work>dir
Volume in drive C is Windows
Volume Serial Number is 6200-9B00
Directory of C:\vsts-agent-win-x64-2.187.2\_work
09/27/2021 09:39 PM <DIR> .
09/27/2021 09:39 PM <DIR> ..
07/30/2021 05:14 PM <DIR> 1
09/14/2021 05:09 PM <DIR> 2
09/14/2021 09:23 PM <DIR> 3
10/05/2021 02:21 PM <DIR> 4
09/23/2021 02:48 PM <DIR> 5
09/29/2021 01:48 PM <DIR> 6
06/25/2021 07:22 PM <DIR> SourceRootMapping
09/22/2021 06:12 PM <DIR> _tasks
10/05/2021 02:22 PM <DIR> _temp
07/02/2021 05:13 PM <DIR> _tool
0 File(s) 0 bytes
12 Dir(s) 107,858,825,216 bytes free
Since many releases and builds fetch different sets of sources it can be beneficial to store the "last set of files" in case the same build wants to run again. So when the same pipeline triggers twice in succession and ends up on the same agent, only the diff needs to be fetched. Depending on how well you've setup your build, you may even be able to perform an incremental build, only updating the files that need updating based on the changes in between this build and the last one. This can drastically speed up builds at the expense of some predictability and with the risk of unexpected outcomes from files left by previous builds.
This is why you can configure for each build what to clean, nothing, just the artifacts, files generated during build, rebuilding the working directory or even flush the whole repo and fetch everything afresh.
Your agent can run a maintenance job to periodically clean up the mess it makes.