次の方法で共有

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

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

重要

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

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

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

  • 清潔
  • ローカル パスを指定する
  • ソースのラベル作成

リポジトリ名

TFVC リポジトリの名前。

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

ビルド パイプラインに必要なフォルダーのみを マップの型値を含めます。 マップされたフォルダーのサブフォルダーに、ビルド パイプラインに必要のないファイルが含まれている場合は、・クロークの型値でマップします。

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

必要のないフォルダー クロークします。 既定では、プロジェクトのルート フォルダーはワークスペースにマップされます。 この構成により、ビルド エージェントはプロジェクトのバージョン管理フォルダー内のすべてのファイルをダウンロードします。 このフォルダーに大量のデータが含まれている場合、ビルドはビルド システム リソースを無駄にし、必要のない大量のデータをダウンロードしてビルド パイプラインを遅くする可能性があります。

プロジェクトを削除するときは、ワークスペースから削除できるマッピングを探します。

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

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

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

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

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

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

注

その場合は毎回新しいエージェントを取得するため、Microsoft でホストされるエージェント を使用している場合、クリーニングは関係ありません。

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

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

  • ソースと出力ディレクトリ: 上記のソース オプションと同じ操作に加えて、$(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 リポジトリは通常、コレクション内のプロジェクトに分散されます。 スコープがコレクション全体の場合にのみアクセスできるフォルダーに対して読み取りまたは書き込みを行っている可能性があります。 これは、組織の設定またはプロジェクト設定の [Pipelines] タブで設定できます。

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

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 は、サーバー上のソース管理とローカル ディスクが同一であることを保証する TFVC 電源ツールです。 Microsoft Visual Studio Team Foundation Server 2015 Power Tools を参照してください。