パイプライン設定

パイプライン設定の編集

コアパイプライン設定を表示および編集するには、右上隅の設定トグルをクリックし、ビジュアルエディターでジョブを囲むパイプラインキャンバス領域内の任意の場所をクリックします。

ビジュアルエディターからコードに切り替えて、マークアップを直接編集することもできます。

パラメーター

パラメーターは、生の値を参照に置き換えるために設計された名前と値のペアです。TeamCity はパラメーター参照（%param-name%）を検出すると、それを実際のパラメーター値に置き換えます。

TeamCity は、パイプラインパラメーターとジョブパラメーターという 2 つのパラメーター層をサポートしています。パイプラインパラメーターは、入力パラメーターと出力パラメーターの両方として利用可能です。

• ジョブパラメーターは、まさにこれらのジョブ、(job.<source-job-ID>.<param-name> 構文を介して) に依存するジョブで使用するために設計されています。詳細については、ジョブパラメーターを参照してください。

• パイプライン入力パラメーターはパイプライン内のすべてのジョブで共有されます。以下のサンプルは、パイプラインパラメーターが 2 つのジョブに伝播される様子を示しています。

  parameters: PipelineParam: foo jobs: Job1: name: Job 1 steps: - type: script script-content: 'echo "Pipeline parameter: %PipelineParam%"' # prints 'foo' Job2: name: Job 2 dependencies: - Job1 parameters: env.Job2Param: '%PipelineParam% bar' # job parameter references pipeline input param steps: - type: script script-content: |- echo "Original pipeline parameter: %PipelineParam%" # prints 'foo' echo "Modified pipeline parameter: %env.Job2Param%" # prints 'foo bar'

• パイプライン出力パラメーターは、このパイプラインがビルドチェーンの一部である場合、下流のパイプラインおよびビルド構成と共有されます。この個別の型を使用することで、どのパラメーターを公開し、どのパラメーターを非公開にするかをより詳細に制御できます。

  出力パラメーターは、同じパイプライン内では使用できないことに注意してください。

  parameters: PipelineInputParam: foo output-parameters: PipelineOutputParam: bar jobs: Job1: name: Job 1 steps: - type: script script-content: |- # Prints 'foo' echo "Input param: %PipelineInputParam%" # Unresolved reference: no compatible agents echo "Output param: %PipelineOutputParam%"

  ビルドチェーン: パイプラインの依存関係のパラメーターの詳細については、このセクションを参照してください。

シークレット

シークレットは、機密データを保存するために設計された保護されたパラメーターです。通常のパラメーターと同様に参照できますが、実際の値は TeamCity UI とビルドログの両方から非表示になります。

パイプラインのコードビューに切り替えると、秘密の値がそれらの値を格納するトークンの名前に置き換えられていることに気付くでしょう。TeamCity は、リモートに保存された設定ファイルを介して秘密データが漏洩するのを防ぐため、これらのトークンを自動的に作成します。

以下のスニペットは、パイプラインの統合セクションでパスワードの代わりに使用できるシークレットを示しています。このシークレットを公開しようとするコマンドラインスクリプトは、ビルドログに「シークレット値: *******」という行を出力します。

パイプラインの依存関係

このセクションでは、単一のビルドチェーンでパイプラインとビルド構成をリンクできます。

パイプライン「B」の設定でオブジェクト「A」への依存関係を追加すると、「A → B」チェーンが作成されます。

• オブジェクト A は単独で動作可能です。

• パイプライン B は、起動時にオブジェクト A を自動的にトリガーします。

「A」は、従来のビルド構成、または別のパイプラインのどちらでも構いません。

パイプラインの依存関係には、以下の設定があります。

依存先

現在編集中のパイプラインを開始する前に完了する必要のある、上流の構成またはパイプラインを選択してください。

リビジョン同期を強制する

TeamCity が、依存関係によってリンクされた両方のオブジェクトが同じリビジョンのコードソースを使用することを保証するかどうかを指定します。

• リビジョン同期が有効になりました : ソースの同じ状態を使用する必要があるセットアップに推奨されます。例: 「A → B」チェーンの場合: 「A」はリビジョン 1.2 で開始され、完了すると「B」に昇格します。「B」のビルドは、最新のリビジョンが 1.4 であっても、同じ 1.2 リビジョンで実行されます。

• リビジョン同期が無効になっています : ビルドに厳密なソース依存関係がない場合（パッケージ化やデプロイのステップなど）は、この設定を使用してください。この場合、ダウンストリームのビルドは利用可能な最新のリビジョンを使用します。例: 「A → B」チェーンの場合: 「A」はリビジョン 1.2 で開始され、完了すると「B」に昇格します。「B」のビルドは、「A」と一致しない最新のリビジョン 1.4 で実行されます。

この設定がビルドチェーンに与える影響の詳細については、強制改訂の同期をオフにするセクションを参照してください。

適切なものがあれば、新しいビルドを実行しないでください

このオプションを有効にすると、適切なソースのリビジョンを持つ別の依存関係ビルドがすでに実行中または完了している場合、TeamCity は新しい依存関係ビルドを実行しません。再利用可能なビルドを判断するために TeamCity が使用する基準の詳細については、適切なビルド物を参照してください。

この場合、依存する（下流の）ビルドがトリガーされると、依存する（上流の）ビルドもキューに追加されます。その後、ビルドチェーンの変更が収集されると、この依存ビルドはキューから削除され、依存関係は適切な完了済みビルドに設定されます。

適切なビルドから成功したビルドのみを使用する

新しくトリガーされたビルドでは、依存関係として正常に完了した適切なビルドのみが使用されます。最新の完了した適切なビルドが失敗した場合は、再実行されます。

依存関係が失敗した場合、依存関係の開始 / キャンセルに失敗した場合

これらの設定により、依存する（下流の）ビルドが、その依存する（上流の）ビルドが失敗した場合に実行されるかどうか、また、実行される場合に、同じビルドの問題が結果に表示されるかどうかを制御できます。

• ビルドを実行しますが、問題を追加する : 依存ビルドが実行され、問題が追加され、ステータスが失敗に変更されます（問題が以前にミュートされていない場合）。

• ビルドを実行しますが、問題を追加しません : 依存ビルドが実行され、問題は追加されません。

• ビルドを開始できなかったものとしてマーク : 依存ビルドは実行されず、「起動に失敗」としてマークされます。

• ビルドをキャンセル : 依存ビルドは実行されず、「キャンセル」としてマークされます。

以下のコードスニペットは、コード内で依存関係を設定する方法を示しています。

自動実行パイプライン

このセクションには、TeamCity が特定の条件でパイプラインを自動的に実行できるようにする設定が含まれています。この機能はトリガーとして利用できます。

新しい変更について

これらの設定により、TeamCity がリポジトリ内の新しい変更を検出するたびに、新しいパイプライン実行がトリガーされます。従来の TeamCity ビルド構成では、VCS トリガーを介して同様の機能が利用できます。

トリガー設定では、どの変更が新しい実行を開始するかを定義します。ブランチトグルを使用して、安定リポジトリブランチを選択します。以下の例では、TeamCity は「本番」リポジトリブランチに変更がコミットされた場合にのみ、パイプラインを自動的に実行します。

プルリクエストトグルは、プルリクエストブランチ（例: GitHub refs/pull/ ブランチ）を利用可能なソースのリストに追加します。このオプションは、パイプラインがこれらのプルリクエストブランチを追跡している場合にのみ有効です（リポジトリセクションを参照）。

スケジュールに従って

これらの設定は、従来のビルド構成のスケジュールトリガーに似ており、TeamCity がパイプラインを実行する日時パターンを定義できます。

リポジトリ

リポジトリセクションを使用すると、パイプライン実行中に複数のリポジトリをチェックアウトできます。TeamCity は、ソースを処理するジョブが設定されていない場合でも、追加されたすべてのリポジトリからソースを取得します。

パイプラインによって自動的に作成される最初のリポジトリエントリは、メインリポジトリと呼ばれます。これは削除できず、追加の YAML ファイルストレージセレクターが含まれています。

リポジトリの URL とソース

パイプラインがチェックアウトするリポジトリを選択できるコアリポジトリ設定。

メインリポジトリでは無効です。

デフォルトのブランチおよびブランチ仕様

これらの設定は、どのブランチ、TeamCity を追跡するかを定義します。追跡されていないブランチは完全に無視されます。つまり、サーバーに変更を報告せず、これらのブランチを実行することはできません。

ブランチ仕様構文の詳細については、次のクラシックビルド構成の記事を参照してください: 共通仕様構文およびデフォルトブランチ。

プルリクエスト

この設定を有効にすると、TeamCity はメインパイプラインページのブランチセレクターにプル (マージ) リクエストブランチを含めます。

また、「新しい変更時」トリガーの関連トグルを有効にして、TeamCity が受信プルリクエストを自動的にビルドするようにすることもできます。

YAML ストレージ

パイプライン YAML 設定を保存する場所を指定します。TeamCity サーバー上またはソースリポジトリ内です。参照: バージョン管理でのプロジェクト設定の保存。

これらの設定はメインリポジトリでのみ使用できます。

リポジトリにステータスを公開する

この設定を有効にすると、TeamCity はパイプラインの実行ステータス（実行中、成功、失敗）を VCS ホスティングプロバイダーに報告します。次の図は、GitHub がこの情報をどのように表示するかを示しています。

クラシックビルド構成の場合、この機能はステータス発行者のコミットビルド機能として利用できます。

リポジトリを追加する際には、既存の接続または VCS ルートを再利用するか、リポジトリの URL を手動で入力するかを選択できます。

各ジョブは、どのパイプラインリポジトリをチェックアウトするかを選択できます。詳細については、次の記事を参照してください: ジョブ設定。

統合

パイプラインとジョブ設定パネルの両方に、プライベート Docker および NPM レジストリに接続するための統合セクションが含まれています。

• パイプライン設定では、ジョブで利用可能な統合の完全なリストを管理します。

• ジョブ設定では、トグルを使用して、ジョブが自動的にログインするレジストリを選択し、ビルドステップが必要なデータにアクセスできるようにします。

クラシック TeamCity ビルド構成は、「接続 + ビルド機能」の組み合わせを通じてこの機能をサポートします。

• Docker 用の Docker レジストリ接続と Docker レジストリ接続ビルド機能。

• NPM レジストリ接続と Node.js レジストリの関連ビルド機能。

プロジェクトにすでに Docker または NPM 接続がある場合は、パイプラインの「統合」セクションに表示されます。

これらの継承された統合は、パイプライン設定パネルから直接編集することはできません。編集するには、プロジェクト設定で元の接続を変更する必要があります。