Team Build: le chemin "Path" est déjà mappé dans l'erreur "workspace" de l'espace de travail même après la suppression de tous les espaces de travail sur l'agent de génération
J'ai ce problème quand je file une compilation. La construction meurt avec l'erreur
Le chemin C:\[Chemin]\Sources est déjà mappé dans l'espace de travail [Nom du serveur].
le même chose que cette question . mais j'ai supprimé tous les espaces de travail sur l'agent de génération en exécutant cette commande:
tf workspaces /remove:*
et aussi en supprimant le dossier de cache TFS. J'ai également redémarré le serveur, mais l'erreur persiste à chaque génération.
Ok, la solution a donc été assez similaire à celle de YeahStu publiée ici . J'ai changé le répertoire de travail de l'agent de compilation de
$(Temp)\UI\$(BuildDefinitionPath)
à
$(Temp)\UI\$(BuildDefinitionPath)\$(BuildDefinitionID)
Ce qui est étrange, c’est que l’autre agent de construction que nous avons fonctionne toujours dans $(Temp)\UI\$(BuildDefinitionPath) et fonctionne bien. La seule différence entre les deux agents est celle qui a cessé de fonctionner si Visual Studio 2010 RC était installé sur celui-ci, tandis que celui qui fonctionnait toujours contenait la version bêta2 de VS2010. Aucune idée pourquoi cela devrait faire une différence.
http://blog.devaffair.com/2011/11/path-is-already-mapped-in-workspace.html
Eh bien, en réalité, ce problème a été résolu dans plusieurs autres questions de ce site, mais je posterai à nouveau ma réponse :)
Ce lien vous dirigera vers un blog qui permettra probablement de résoudre votre problème le plus rapidement possible.
Je pense que le problème n'apparaît que si vous avez plusieurs agents de génération sur un même groupe de construction.
J'ai pu supprimer l'espace de travail. Sur le serveur de compilation, procédez comme suit:
Téléchargez psExec depuis sysinternals.
http://technet.Microsoft.com/en-us/sysinternals/bb897553
Ouvrez cmd en tant qu'administrateur.
Exécutez psexec pour ouvrir cmd en tant que service réseau.
psexec -i -u "nt autorité\service réseau" cmd.exe Cela ouvre une autre fenêtre cmd que "nt autorité\service réseau" utilise.
Exécutez un "whoami" pour vous assurer que vous êtes maintenant "nt autorité\service réseau".
Ouvrez Visual Studio en tapant devenv.
Dans visual studio\team Explorer, connectez-vous au serveur de contrôle de code source
Dans Visual Studio\Source Control Explorer, jetez les espaces de travail incriminés.
Je ne sais pas pourquoi, mais les espaces de travail tf/remove ne fonctionnaient pas pour moi.
Je pense que votre problème peut-être à avoir avec 3 agents de build qui ne sont pas étiquetés. Je pense que l’espace de travail, s’il est laissé derrière, est supprimé par l’agent qui effectue la construction. S'il s'agit d'un agent différent de l'agent qui a créé l'espace de travail, il y aura des problèmes évidents.
Pour résoudre le problème, procédez comme suit: Nommez un agent, l'agent par défaut. Cela n'aura pas de balises. Dans les deux autres agents, dans les propriétés, ajoutez une balise pour les agents, une pour chaque agent et sélectionnez-la.
Désormais, toute construction exécutée sans jeu de balises utilisera toujours l'agent par défaut.
Pour qu'une version utilise l'un des autres agents, ouvrez la définition de construction et accédez à la section avancée de Processus.
Ouvrez les paramètres de l'agent et sélectionnez le filtre Ellipsis dans les balises, puis entrez une balise du même nom pour la balise entrée sur l'agent de génération que vous souhaitez utiliser.
Vous devrez peut-être nettoyer les espaces de travail avant la première exécution.
Ce qui précède vous permet de contrôler quel agent de génération est utilisé pour chaque définition de construction. Par conséquent, vous devriez également mettre fin à votre problème d'espace de travail.
Plus d'informations sur la propriété du répertoire de travail ici:
http://msdn.Microsoft.com/en-us/library/bb399135.aspx
Cependant, dans la version RTM, "$ (HOMEDRIVE)" n'est pas reconnu. Peut-être à cause de l'enveloppe; ne l'avez pas testé, alors soyez conscient de cette faille dans la documentation.
==== Visual Studio 2010 ====
Je ne pouvais pas voir les espaces de travail "défectueux" dans TFS Sidekick et ne pouvais donc pas les supprimer. Les étapes décrites par David Osborne m'ont orienté dans la bonne direction. J'ai pu voir les espaces de travail "défectueux" dans TFS Sidekick et enfin les supprimer.
On the build server do this:
Download psExec from sysinternals.
http://technet.Microsoft.com/en-us/sysinternals/bb897553
Open cmd as Administrator.
Run psexec to open cmd as Network Service.
psexec -i -u "nt authority\network service" cmd.exe That opens another cmd window that "nt authority\network service" is using.
Run a “whoami” to make sure you’re now "nt authority\network service".
Open visual studio by typing C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.
When asked use the login from the TFS buildagent account to start Visual Studio.
Within visual studio\team Explorer, Connect to the source control server
Within visual studio\ source control Explorer, throw away the offending workspaces.
Delete the "faulty" workspaces with TFS SideKick.
Maintenant, le problème était résolu.
Changé en
$ (Temp)\UI\$ (BuildDefinitionPath)\$ (BuildDefinitionID)
le fait fonctionner mais pas pour 100% des situations. Chaque fois que la construction échouait (par exemple une erreur dans les codes source ou quelque chose), puis après avoir corrigé l'erreur et essayé d'exécuter à nouveau la construction en équipe, il échouait sur "Workspace XYZ est déjà mappé ...", puis je dois le supprimer manuellement mappage de l'espace de travail par "Team Foundation Sidekick 2010" et exécution de la création d'une nouvelle équipe pour réussir. La prochaine fois que la même équipe est créée plus d'une fois, elle est réussie, mais jusqu'à ce qu'une construction d'équipe échoue en fonction d'une erreur du code source, elle recommence à lancer des erreurs de "mappage d'espace de travail".
Il me semble que TFS 2010 présente un problème lorsque la construction d’une équipe échoue, ne supprime pas/ne supprime pas l’espace de travail utilisé ou quelque chose de similaire.
Est-ce que quelqu'un a les mêmes problèmes?
J'ai eu le même problème - il fonctionnait bien jusqu'à ce que j'ai installé VS2010 sur l'agent de génération. L'ajout de BuildDefinitionId a corrigé le problème, mais il est étrange que l'installation de VS2010 perturbe les espaces de travail déjà configurés et en cours d'exécution.