web-dev-qa-db-ja.com

チームビルド:ビルドエージェントのすべてのワークスペースを削除した後でも、パス「パス」はすでにワークスペース「ワークスペース」エラーにマップされています

ビルドをキューに入れるときにこの問題が発生します。ビルドがエラーで終了します

パスC:\ [Path]\Sourcesはすでにワークスペース[サーバー名]にマップされています。

この質問と同じ 。ただし、次のコマンドを実行して、ビルドエージェントのすべてのワークスペースを削除しました。

tf workspaces /remove:*

また、TFSキャッシュフォルダーを削除します。サーバーも再起動しましたが、ビルドごとにエラーが発生し続けます。

25
Glenn Slaven

さて、ソリューションはYeahStu ここに投稿 とかなり似ていることになりました。ビルドエージェントの作業ディレクトリをから変更しました

_$(Temp)\UI\$(BuildDefinitionPath)
_

_$(Temp)\UI\$(BuildDefinitionPath)\$(BuildDefinitionID)
_

奇妙なことに、私たちが持っている他のビルドエージェントはまだ$(Temp)\UI\$(BuildDefinitionPath)で実行されており、正常に動作しています。 2つのエージェントの唯一の違いは、動作を停止したエージェントにVisual Studio 2010 RCがインストールされているのに対し、動作しているエージェントにはVS2010Beta2がインストールされていることです。なぜこれが違いを生むのか分かりません。

20
Glenn Slaven

http://blog.devaffair.com/2011/11/path-is-already-mapped-in-workspace.html

まあ、実際にはこの問題はこのサイトの他のいくつかの質問で解決されていますが、私は再び私の答えを投稿します:)

このリンクはおそらくあなたの問題を最も速く解決するであろうブログにあなたを導くでしょう

4
Devaffair

この問題は、1つのビルドボックスに複数のビルドエージェントがある場合にのみ発生すると思います。

3
wesen

ワークスペースを削除することができました。ビルドサーバーでこれを行います。

SysinternalsからpsExecをダウンロードします。
http://technet.Microsoft.com/en-us/sysinternals/bb89755

管理者としてcmdを開きます。

Psexecを実行して、cmdをネットワークサービスとして開きます。
psexec -i -u "nt Authority\network service" cmd.exeこれにより、 "nt Authority\networkservice"が使用している別のcmdウィンドウが開きます。

「whoami」を実行して、「nt Authority\networkservice」になっていることを確認します。

Devenvと入力して、VisualStudioを開きます。

Visual Studio\Team Explorer内で、ソース管理サーバーに接続します

Visual Studio \ソース管理エクスプローラー内で、問題のあるワークスペースを破棄します。

理由はわかりませんが、tfワークスペース/ removeが機能していませんでした。

1
David Osborne

あなたの問題は、タグ付けされていない3つのビルドエージェントがあることに関係していると思います。ワークスペースが取り残された場合、ビルドを実行しているエージェントによって削除されると思います。ワークスペースを作成したエージェントとは別のエージェントである場合は、明らかな問題が発生します。

したがって、問題を修正するには、次のことを行う必要があります。 1つのエージェントにデフォルトエージェントを指定します。これにはタグがありません。他の2つのエージェントでは、プロパティでエージェントのタグを追加します。エージェントごとに1つ、それを選択します。

これで、タグが設定されていないビルドが実行されると、常にデフォルトエージェントが使用されます。

他のエージェントのいずれかを使用するビルドを取得するには、ビルド定義を開き、プロセスの詳細セクションに移動します。

エージェント設定を開き、[タグフィルター]の省略記​​号を選択して、使用するビルドエージェントに入力したタグと同じ名前のタグを入力します。

最初の実行の前に、ワークスペースをクリアする必要がある場合があります。

上記を実行すると、各ビルド定義に使用されるビルドエージェントを制御できるため、ワークスペースの問題も停止するはずです。

1
Alex

作業ディレクトリのプロパティの詳細については、こちらをご覧ください。

http://msdn.Microsoft.com/en-us/library/bb399135.aspx

ただし、RTMバージョン "$(HOMEDRIVE)"は認識されません。ケーシングが原因である可能性があります。テストしていないため、ドキュメントの欠陥に注意してください。

0
user1228

==== Visual Studio 2010 ====

TFS Sidekickで「障害のある」ワークスペースを確認できなかったため、それらを削除できませんでした。デビッドオズボーンが説明した手順は、私を正しい方向に向けました。 TFS Sidekickで「障害のある」ワークスペースを確認でき、最終的にそれらを削除できました。

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.

これで問題は解決しました。

0
Robert Harwig

に変更されました

$(Temp)\ UI\$(BuildDefinitionPath)\ $(BuildDefinitionID)

それは機能しますが、100%の状況では機能しません。ビルドが完了しなかった場合(たとえば、ソースコードのエラーなど)、エラーを修正してチームビルドを再度実行しようとすると、「ワークスペースXYZは既にマップされています...」で失敗します。手動でこれを削除する必要があります。 「TeamFoundationSidekick 2010」によるワークスペースマッピングを行い、チームビルドを再度実行して成功させます。次回、同じチームビルドを複数回実行すると、正常にビルドされますが、ソースコードのエラーによってチームビルドが失敗するまで、「ワークスペースマッピング」エラーが再びスローされ始めます。

TFS 2010には、チームビルドが失敗したり、使用されているワークスペースがクリア/削除されなかったりするなどのバグがあるようです。

同じ問題が発生していますか?

0
psulek

同じ問題が発生しました。ビルドエージェントにVS2010をインストールするまでは正常に実行されていました。 BuildDefinitionIdを追加すると修正されましたが、VS2010をインストールすると、すでにセットアップされ実行されているワークスペースが台無しになるのは不思議です。

0
codemonkey