TFVC: Deleting workspace fails during vnext build

Question

we are running TVFC with "Azure DevOps Server" 2019 Update1.

At the end of our vnext build, we want to delete the workspace. We do this using tf.exe. But we have to specify the workspace owner, because the account that runs the build (meaning the account that is configured for the build service on the build agent) is different from the account used to create the workspace.

The workspace owner is "Project Collection Build Service (DefaultCollection)". So as command to delete the workspace we use e.g.:

tf.exe workspace /delete /noprompt /collection:http://tfs.siplaceworld.net:8080/tfs/DefaultCollection/ ws_1749_167;Project Collection Build Service (DefaultCollection)

This works most of the time. Sporadically we get an error message saying:

TF14061: The workspace ws_1749_167;Project Collection Build Service (DefaultCollection) does not exist.

But the workspace does exist when looking at the build computer. So for debug perpose I have added a call to "tf.exe workspaces" to get a list of all workspaces, before we try to delete.

In the error case, you see that the workspace owner is not in english, but in german:

tf.exe workspaces /collection:http://tfs.siplaceworld.net:8080/tfs/DefaultCollection/
Collection: http://tfs.siplaceworld.net:8080/tfs/DefaultCollection
Workspace   Owner                                               Computer  Comment
----------- --------------------------------------------------- --------- -------
MCHC16074   ASM AS SW-Dev Build                                 MCHC16074 
ws_1678_167 Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_1693_167 Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_1695_167 Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_1700_167 Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_1719_167 Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_1744_167 Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_1747_167 Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_1749_167 Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_461_169  Builddienst für Projektsammlung (DefaultCollection) MCHC16074 
ws_470_169  Builddienst für Projektsammlung (DefaultCollection) MCHC16074

This is sporadic and we have no idea on what it depends. How is it possible that the workspace owner is sometimes listed in german and sometimes in english?

Any help appreciated!

can you use `Build.QueuedBy` and `Build.Repository.Tfvc.Workspace` variables? https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#build-variables — Shayki Abramczyk, Aug 03 '20 at 13:14
Yes I can. I already use the variable $(Build.Repository.Tfvc.Workspace) for dtermining the workspace, but this does not give me the owner. And the workspace owner is not the persion who queued the build... — PainElemental, Aug 03 '20 at 13:56
if it's CI/scheduled builds the value of `Build.QueuedBy` is The system identity, for example: `[DefaultCollection]\Project Collection Service Accounts` see in the bottom of the page https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#system-variables — Shayki Abramczyk, Aug 03 '20 at 14:00
*At the end of our vnext build, we want to delete the workspace.* Why? The build engine handles workspace mappings for you. — Daniel Mann, Aug 03 '20 at 14:49
Why? Because there are several hundred build definitions that would leave their workspaces on the build computers. That's why we want to clean up after the build is finished. The build engine only offers to clean the workspace at the start of a build, but not at the end :( — PainElemental, Aug 03 '20 at 16:52
That's a cache for the next time you run the build; it's good behavior, not something you should be trying to prevent. — Daniel Mann, Aug 03 '20 at 19:38
I don't want that cache, because it eats up all disk space ;) — PainElemental, Aug 04 '20 at 05:07

PainElemental · Answer 1 · 2020-08-04T05:22:16.537

"Project Collection Build Service (DefaultCollection)" is only the display name of the account that creates the workspace. No idea why this is sometimes english and sometimes german, but you can use the "real" username instead of the display name.

I found the username of this account in the Security-Window of "Source Control Explorer". I selected to "Add a Windows user or group" and searched for "Build" and there it was:

Display Name: Project Collection Build Service (DefaultCollection)

User name: Build\beb2741f-e779-4a6f-a20e-033796fec5b7

So I changed the task to cleanup the build agent to use the username when deleting the workspace:

tf.exe workspace /delete /noprompt /collection:http://tfs.siplaceworld.net:8080/tfs/DefaultCollection/ ws_1749_167;Build\beb2741f-e779-4a6f-a20e-033796fec5b7

Works great :)

score 1 · Accepted Answer · answered Aug 04 '20 at 06:18

1

To delete an existing workspace, you must be the owner or have the global Administer workspaces permission set to Allow.

You could also try to use onwer uniq ID instead of name. Get the owner uniq ID:

tf vc workspaces ws_1749_167 /computer:* /format:xml /collection:https://dev.azure.com/xxx/

After this it will return the info of owner uniq ID . Then delete the workspace with owner uniq ID:

tf workspace /delete ws_1749_167;{owner uniq ID}

For details , please refer to this ticket.

answered Aug 04 '20 at 06:18

Hugh Lin

17,829
2
21
25

1

Thank you. One of the OwnerAliases is the same as the username that I see when looking in the security-window (see my other answer). Build\beb2741f-e779-4a6f-a20e-033796fec5b7 beb2741f-e779-4a6f-a20e-033796fec5b7 Project Collection Build Service (DefaultCollection) So I guess it doesn't matter if I use the first or second alias for deleting the workspace... – PainElemental Aug 04 '20 at 06:49

TFVC: Deleting workspace fails during vnext build

2 Answers2