問題タブ [gated-checkin]

私は最近VSSからTFS2010に移行し、それを絶対に気に入っていますが、まだ思ったとおりに機能することができていないことがあります。

目標

開発への変更がビルドを壊すときをすぐに知りたいです。事後的にわかったとしても、大したことではありません。1日を通して多くのチェックインが行われるため、ビルドが完了するのを待ちたくないので、非同期にする必要があります。

メインブランチでは、マージが発生するたびに、ビルドが中断されないようにします。これについてすぐにフィードバックが欲しいです。Mainにマージすることはあまりないので、待機時間は問題ありません。

現在の設定

私の解決策はMainというフォルダの下にあります。私はそれから開発と呼ばれるブランチを作りました。私が作業しているワークスペースは、メインブランチと開発ブランチの両方を含むトップレベルに関連付けられています。問題が発生した場合に備えて、開発のみを指すようにワークスペースを調整してみました。それで問題が解決したようには見えなかったので、メインと開発の両方で、元の状態に戻しました。

ワークスペースのビルド定義内に、2つの定義が定義されています。1つはメインブランチ用で、もう1つは開発用です。

最初の定義は、メインブランチを構築するためのものです。ゲートチェックイントリガーがあり、「作成するアイテム」はメイン内のソリューションファイルを指します。

2番目の定義は、開発ブランチでソリューションを構築するためのものです。Rolling Buildsトリガーがあり、「ItemstoBuild」は開発内のソリューションファイルを指します。

結果

現在、開発で変更が行われ、チェックインが実行されると、メインへのゲートチェックインがトリガーされます。これは混乱を引き起こすだけでなく、プロセス全体の速度を低下させる傾向があります。

次のステップ

分岐、一般的なTFSの使用法などに関するTFSガイドのいくつかを見てきました。残念ながら、問題の解決策はまだ見つかりません。以前にこの問題に遭遇したことがある場合は、何か提案をいただければ幸いです。

TFS2010 SP1 でカスタム MSBuild スクリプトを使用してビルドを行っています。ビルド タイプはゲート付きチェックインであり、ビルドで MSBuild ログが成功と表示されていても失敗します。MSBuild が完了した後、ビルド定義がゲート チェックインを完了する前に失敗を引き起こす原因

ゲート チェックイン ポリシーを設定しようとしていますが、ワークフローで問題が発生しています。

ビルド定義メニューで、Trigger -> Gated Check-in を選択します。これは私にエラーを与えます...

「トリガー タブで選択したトリガーは、プロセス タブで指定したビルド プロセス テンプレートでは使用できません。(ビルド理由の Manual、IndividualCI、BatchedCI、Scheduled、ScheduleForced、UserCreated をサポートしています)」

サポートされているビルド理由をどこで選択できるかについて、誰か考えがありますか?

.xaml ファイル内のすべてのコードに目を通しましたが、問題となるものは何も見つかりませんでした。

ここで何か助けていただければ幸いです。

どのビルドにどの変更セットが含まれていたかを取得するには、Team Foundation Sidekicks の「Label Sidekick」を使用します。ここで、ビルドのラベルを配置し、新しくビルドされた変更セットを見つけることを期待します。

TFS 2010 での開発プロセスは「ゲート」チェックインを使用しているため、最新のチェックインが Sidekicks に表示されないという状況に直面しています (実際には以前のビルドの変更セットを受け取ります)。ラベル付けが行われる時点では、最新の変更がまだコミットされていないため、これは説明できます。

BuildLog は、関連する変更セットを正しく報告します。

ビルド プロセス テンプレートでいくつかの実験を行いましたが、必要なものが得られないようです。たとえば、Labeling アクティビティを「Run On Agent」スコープの外に配置すると、最初に「オブジェクト参照がオブジェクトのインスタンスに設定されていません」というエラーが表示されてビルドが失敗します。(これは、2 番目の部分を実行するために「ラベル」変数と「ワークスペース」変数の範囲を広げなければならなかったという事実に関連していると思います)。
この試行のビルド プロセス テンプレートの「前」の状態はこちら(これは機能します)、「後」の状態 (「オブジェクト参照が設定されていません..」) はこちらです。

要約すると、次の 2 種類の入力が役に立ちます。

ゲート チェックインがコミットされた後にラベル付けが行われるようにするには、ビルド プロセス テンプレートをどのように変更すればよいですか? (-- これにより、Sidekicks での表示が合理化されます)

また

各ビルドの関連する変更セットをプログラムで取得するにはどうすればよいですか? (-- これにより、Sidekicks の角度を時代遅れにする可能性のある小さなアプリを作成できるようになります)

対応するフォルダに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で使用できます。

私は TFS 2010 を使用しています。現在、トランク (MAIN) ブランチでのみ Gated Check-in ビルドを使用しています。また、DEV ブランチと RELEASE ブランチでは CI を使用しています。

• すべてのブランチで Gated Check-in ビルドを使用しないのはなぜですか?
• DEV および RELEASE ブランチで Gated Check-in ビルドを使用すべきでないシナリオはどれですか?
• すべてのブランチで常に Gated Check-in ビルドを使用する方が良いですか?

ゲート チェックインで TFS2010 を使用しています。「Associate Chagesets and Work Items」を false に設定しても、変更セットと作業項目がこのビルドに関連付けられています。

これは、ゲート ビルドでのみ発生します。他のチェックイン トリガー (手動、連続、スケジュール) を使用してビルドを実行すると、[変更セットと作業項目の関連付け] が true に設定されていない限り、変更セットと作業項目はビルドに関連付けられません。

なぜこれが起こっているのですか？デフォルトのワークフロー定義で Visual Studio スクラム プロセス テンプレートを使用しています。ワークフローの定義に問題があるのではないでしょうか?

この質問は 、ゲート チェックインを防止してキーワード ***NO_CI*** をコメントに入れる方法に移動しました。

ここで、得た知識を使用して質問をより詳細に説明します

コードの品質と単体テストを確実にするために、プロジェクトにゲート チェックイン ビルドを確立しました。

また、チェックイン後にビルドしたいチェックイン (継続的統合ビルド) によってトリガーされる別のビルド定義があります。

私の期待は、ゲート チェックインが実行され、(ビルド サービス ユーザーによる) ビルドとコミットが成功した後、他のビルドがトリガーされることでした。

しかし、これはそうではありません。

ビルド サービスからのチェックインによって継続的インテグレーション ビルドもトリガーされるという、これを機能させる方法を知っている人はいますか

新しいファイルを追加するときに、MVC3 プロジェクトのゲート チェックイン シナリオで「ラベルを適用できませんでした」というメッセージが表示されます。

いくつかのグーグルの後、MSBuildスクリプトを使用して追加の処理を行っているためのようです: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/af9c65a2-dc27-40df-ae6d -958008ad106f

ソリューションのリリース ビルドを実行すると、MVC AREA を使用しているため、TFS がバイナリを完全に間違ったフォルダーに配置しているように見えるため、「余分なもの」が必要です。そのため、TFSBuild.proj は別の MSBuild ファイルを呼び出してファイルのコピーを行っています。TFS2010 のやり方、つまり Windows ワークフローを理解するための専門知識はありません。

問題は、Gated Check-in を引き続き使用しながら、ラベルの問題を適用してこれを修正するにはどうすればよいかということです。

乾杯、
ピート

これをここに投稿するかどうか迷っていましたが、TFS に関する他の同様の投稿をここで見ましたが、問題が解決しなかったため、先に投稿することにしました。

元同僚がセットアップした TFS ボックスを修正しようとしています。日付までファイルをチェックイン/チェックアウトする以外の目的で TFS を使用したことはありません。 TFS にチェックインしようとしています。ゲート チェックインを有効にしており、下の赤いボックスで強調表示されているように、ユーザーがビルド検証をバイパスすることも許可していません。

問題は、すべてのゲート チェックイン試行がエラーで失敗することです。

部分的に成功したというメッセージ プロンプトが表示される

ビルドを開くと、これが表示されます

これをオンラインで確認したところ、グレー表示されているチェックボックスを有効にして、ユーザーが検証をバイパスできるようにすることが解決策であることがわかりました。私はこれが事実であってほしくありません。バイパス検証を無効にしたまま、ゲート チェックインを機能させる方法はありますか?

これは私を完全に困惑させ、何が間違っていたのか理解できません。何が問題なのかを調べるためにログのどこを参照すればよいかについての指針もおそらく役立つでしょう。ログには、警告やエラーなしでビルドが成功したことが示されています。