7

対応するフォルダに2つのソリューションがあります。

  1. SolutionA\SolutionsA.sln
  2. SolutionB\SolutionB.sln

各ソリューションには、ゲートチェックインビルドが構成されています。つまり、2つのビルド定義GatedSolutionAとGatedSolutionBです。

現在、両方のフォルダーの変更を一緒にチェックインすると、TFSは、変更セットに対して実行するビルド（GatedSolutionA、GatedSolutionBでドロップダウン）を選択するためのダイアログボックスを表示します。私のチェンジセットには、ソリューションBに重大な変更があり、ソリューションAに重大でない変更があります。つまり、Build GatedSolutionBは失敗しますが、GatedSolutionAは合格します。

チェンジセットに対してビルドするためにGatedSolutionAを選択すると、TFSがそれをチェックインします。これにより、ソリューションBが壊れた状態のままになり、ソリューションBのゲートチェックインの目的が無効になります。

ビルド定義のトリガーをCIに変更すると、TFSは両方のビルドをキューに入れます。

私が探しているのは同じ動作です。つまり、すべてのゲートビルドがキューに入れられ、そのうちの1つが失敗した場合、チェンジセットは拒否されます。

注：両方のソリューションに対して単一のビルド定義を作成したくありません。また、2つの別々のチェンジセットを作成することでこの問題の発生を回避できることはわかっていますが、これは通常、開発者が作業中以外のソリューションのためにチェックインされているファイルがあることに気付いていない場合に発生します。

2019年の更新

TFSとAzureDevOpsがGITとプルリクエストの使用を開始したため（マスターブランチで）ブランチポリシーを使用して、パスの変更など、複数のビルドチェックを追加SolutionA\*できます。BuildAは、キューに入れてチェックするように構成できます。同様に、パスSolutionB\*、BuildBはキューに入れてチェックするように構成できます。その結果、両方のパスに変更があるコミットの場合、チェックのために両方のビルドがキューに入れられます。GITを使用するのを待つ価値はありました。

ブランチポリシー：https ：//docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies？view = azure-devops＃build-validation

注：ドキュメントはパスフィルターを表示するように更新されておらず、ここhttps://github.com/MicrosoftDocs/vsts-docs/issues/3235でgithubに欠陥が発生しています。そのため、フィルターはAzureDevOpsおよびServerで使用できます。

4

4 に答える 4

3

@Gchavesはその問題の解決策を見つけました。「ソース管理フォルダー」を、SolutionAがある内部フォルダーに構成する場合は、「ビルド定義の編集」に移動し、「ワークスペース」タブに移動できます。

たとえば、このファイルシステムがある場合：

  1. Projects \ SolutionA \ SolutionA.sln
  2. Projects \ SolutionB \ SolutionB.sln

これで、「ソース管理フォルダー」と「ビルドエージェントフォルダー」をProjects \ SolutionAに構成すると、GatedチェックインはSolutionAをチェックインしようとしたときにのみトリガーされ、SolutionA.slnのみがコンパイルされます（これがtrueになるため） [プロセス]タブ->1.Required->ProjectsToBuildでSolutionA.slnをポイントする必要があります）

そして、同じワークスペースの下に複数のソリューションを配置し、個別に構築、チェックイン、ラベル付けを行うことができます:)

于 2011-09-29T10:50:54.967 に答える
1

[プロセス]タブのビルド定義で、ビルドする複数のslnを選択できます。

于 2011-06-14T08:39:00.997 に答える
0

この問題の1つの解決策は、開発者が個別のソリューション用に個別のワークスペースをマップすることです。ソリューション間に重複するコードがなく、開発者が別のソリューションを構築するためにゲートされたときに1つのソリューションにチェックインできないようにする場合は、異なるワークスペースを使用する必要があります。

SolutionAのWorkspaceAとSolutionBのWorkspaceBがある場合、[保留中の変更]ダイアログには、適切なワークスペースに加えられた変更のみが表示されます。

あなたが言うように、あなたはあなたが別々のチェンジセットを使うことによってそれを避けることができることを知っています。これは、開発者に2つの別々のチェンジセットを使用するように「強制」し、「開発者が認識していない...」という状況を回避する方法です。

彼らのワークスペースを作成し、「ワークスペースの作成」権限を取り消して、両方の領域を含むワークスペースを作成できないようにします。

于 2011-07-20T21:17:05.833 に答える
0

「両方のソリューションに対して単一のビルド定義を作成したくない」とおっしゃっていたと思いますが、実際には、ここで実行できるのはあなただけです。私が提案するのは、機能開発用と統合用の2つのブランチを持つことです。開発者に機能ブランチで作業してもらい、それらのソリューションにゲートチェックイン（またはCI）ビルドを使用してもらいます。機能ブランチの変更を、すべてのソリューションをビルドする単一のゲート付きチェックインビルド定義を持つ統合ブランチに定期的にマージします。これにより、統合ブランチからのビルドがクリーンに保たれます。

于 2011-12-19T14:59:12.837 に答える