TFVC リポジトリをビルドする

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

重要

TFVC はクラシック パイプラインでのみサポートされ、YAML はサポートされません。

ビルドするリポジトリを選択する

TFVC リポジトリを使用するパイプラインを編集するときに、次のオプションを使用できます。

  • Clean
  • ローカル パスの指定
  • ソースのラベル作成

リポジトリ名です

TFVC リポジトリの名前。

マッピング (ワークスペース)

種類の値 "マップ" を使用して、ビルド パイプラインに必要なフォルダーのみを含めます。 マップするフォルダーのサブフォルダーに、ビルド パイプラインで不要なファイルが含まれる場合は、種類の値 "クローク" を使用してマップします。

ビルド パイプラインに必要なファイルを含むすべてのフォルダーがマップされていることを確認してください。 たとえば、別のプロジェクトを追加する場合は、ワークスペースに別のマッピングを追加しなければならない可能性があります。

不要なフォルダーはクロークしてください。 既定では、ワークスペースにおいてプロジェクトのルート フォルダーがマップされます。 この構成では、ビルド エージェントが、プロジェクトのバージョン コントロール フォルダー内のすべてのファイルをダウンロードします。 このフォルダーに多くのデータが存在する場合、必要のないデータが大量にダウンロードされるため、ビルドでビルド システム リソースが浪費され、ビルド パイプラインの処理が遅くなるおそれがあります。

プロジェクトを削除するときは、ワークスペースから削除できるマッピングがないか確認してください。

これが CI ビルドの場合は、通常、これらのマッピングが [トリガー] タブの CI トリガーのフィルター設定と一致していることを確認する必要があります。

TFVC ワークスペースを最適化する方法の詳細については、「ワークスペースの最適化」を参照してください。

エージェントのローカル リポジトリをクリーニングする

ビルドの実行前に、セルフホステッド エージェントの作業ディレクトリに対してさまざまな形式のクリーニングを実行できます。

一般に、セルフホステッド エージェントのパフォーマンスを向上させるには、リポジトリをクリーンしないでください。 このケースでは、最適なパフォーマンスを得るために、ビルドに使用するタスクまたはツールのクリーン オプションを無効にして、インクリメンタル ビルドを実行するようにもしてください。

(以前のビルドの残留ファイルによる問題を回避する目的などで) リポジトリをクリーンする必要がある場合は、以下のオプションを使用できます。

注意

Microsoft ホステッド エージェントを使用している場合、このケースでは新しいエージェントが毎回提供されるため、クリーニングは関係ありません。

リポジトリをクリーニングする場合は、true を選択し、次のいずれかのオプションを選択します。

  • ソース: ビルド パイプラインは、$(Build.SourcesDirectory) の下で、変更を元に戻し、現在のワークスペースの scorch を実行します。

  • ソースおよび出力ディレクトリ: 上記の [ソース] オプションと同じ操作に加えて、$(Build.BinariesDirectory) を削除して再作成します。

  • ソース ディレクトリ: $(Build.SourcesDirectory) を削除して再作成します。

  • すべてのビルド ディレクトリ: $(Agent.BuildDirectory) を削除して再作成します。

CI トリガー

ユーザーがコードでチェックインするたびにビルドが実行されるようにする場合は、[トリガー] タブで [継続的インテグレーションを有効にする] を選択してこのトリガーを有効にします。

CI トリガー。

バッチ変更

多数のチーム メンバーが頻繁に変更をアップロードする場合に、実行するビルドの数を減らすには、このチェック ボックスをオンにします。 このオプションを選択した場合は、ビルドが実行されているとき、システムはビルドが完了するまで待機し、まだビルドされていないすべての変更の別のビルドをキューに入れます。

変更をバッチ処理し、まとめてビルドすることができます。

パス フィルター

追加および除外するバージョン コントロール パスを選択します。 ほとんどの場合、これらのフィルターが TFVC マッピングと一致していることを確認する必要があります。 パス フィルターを使用すると、ビルドをトリガーするファイルのセットを削減することができます。

ヒント:

  • パスは常に、ワークスペースのルートからの相対位置で指定します。
  • パス フィルターを設定しない場合は、既定で、ワークスペースのルート フォルダーが暗黙的に含められます。
  • パスを除外した場合は、より深いフォルダーを指すよう修飾しない限り、それを含めることはできません。 たとえば、/tools を除外した場合、/tools/trigger-runs-on-these を含めることはできます
  • パス フィルターの順序は関係ありません。

ゲート チェックイン

ゲート チェックインを使用すると、破壊的変更から保護できます。

既定では [フィルターにワークスペース マッピングを使用] が選択されています。 ソース マッピングで指定されたパスで変更がチェックインされるたびにビルドがトリガーされます。

そうしない場合は、このチェック ボックスをオフにし、トリガーにパスを指定することができます。

開発者に与える影響

開発者は、チェックインしようとすると、変更をビルドするよう求められます。

ゲート チェックインのダイアログの表示

その後、システムでシェルブセットが作成され、ビルドされます。

注意

"The shelveset _Build_95;Build\6bc8a077-3f27-4936-82e6-415fbd53ba07 could not be found for check-in" などのエラーが発生した場合は、[非リリース パイプラインのジョブの承認スコープを現在のプロジェクトに制限する] の設定を確かめ、有効になっていないことを確認してください。

ゲート チェックイン エクスペリエンスの詳細については、ゲート チェックイン ビルド パイプラインによって制御されるフォルダーへのチェックインに関する記事を参照してください。

CI ビルドを実行するオプション

既定では、CI ビルドは、ゲート チェックイン プロセスが完了し、変更がチェックインされた後には実行されません。

それでも、ゲート チェックインの後に CI ビルドを実行させる必要がある場合は、[コミットされた変更の CI トリガーを実行する] チェック ボックスをオンにします。 これを行うと、ビルド パイプラインによって ***NO_CI*** が変更セットの説明に追加されません。 その結果、チェックインの影響を受けた CI ビルドが実行されます。

その他の注意事項

よく寄せられる質問

パイプラインを実行すると、次のエラーが発生します。

The shelveset <xyz> could not be found for check-in

  • ジョブ承認スコープがコレクションに設定されていますか? TFVC リポジトリは通常、コレクション内のプロジェクトに分散されています。 スコープがコレクション全体である場合にのみアクセスできるフォルダーに対して、読み取りまたは書き込みを行っている可能性があります。 この設定は、[パイプライン] タブにおける組織の設定またはプロジェクトの設定で行うことができます。

パイプラインを実行すると、次のエラーが発生します。

The underlying connection was closed: An unexpected error occurred on a receive. ##[error]Exit code 100 returned from process: file name 'tf', arguments 'vc workspace /new /location:local /permission:Public

  • これは通常、サービスで技術的な問題が生じているときに発生する断続的なエラーです。 パイプラインを再実行してください。

scorch とは何ですか?

scorch とは、サーバー上のソース コントロールとローカル ディスクを同一に保つ TFVC パワー ツールです。 「Microsoft Visual Studio Team Foundation Server 2015 Power Tools」を参照してください。