パイプライン設定 | TeamCity On-Premises ドキュメント

パイプライン設定の編集

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

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

パラメーター

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

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

ジョブパラメーターは、まさにこれらのジョブ、(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 は、リモートに保存された構成ファイルを通じてシークレットデータが漏洩するのを防ぐため、これらのトークンを自動的に作成します。

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

jobs:
  Job1:
    name: Job 1
    steps:
      - type: script
        script-content: |-
          echo "Secret value: %registry-password%"
secrets:
  registry-password: credentialsJSON:c57c2732-1d8c-4c11-8724-f275085f4320

  

パイプラインの依存関係

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

パイプライン「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" は最新の 1.4 リビジョンで実行されます。

この設定がビルドチェーン全体に与える影響については、リビジョンの同期を参照してください。

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

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

この場合、ダウンストリームビルドがトリガーされると、アップストリームビルドは引き続きキューに追加されます。その後、チェーンの変更が収集されると、このアップストリームビルドはキューから削除され、代わりに依存関係が適切な完了済みビルドにリンクされます。

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

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

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

これらの設定では、アップストリームビルドが失敗した場合にダウンストリームビルドを実行するかどうか、また実行する場合に同じビルド問題を結果に表示するかどうかを制御できます。

ビルドを実行するが、問題を追加: ダウンストリームビルドが実行され、問題が追加されて、ステータスが失敗に変わります(問題が以前にミュートされていた場合を除く)。
ビルドを実行するが、問題を追加しない: ダウンストリームビルドが実行され、問題は追加されません。
ビルドを開始失敗としてマーク: ダウンストリームビルドは実行されず、" 起動に失敗" としてマークされます。
ビルドをキャンセル: ダウンストリームビルドは実行されず、" キャンセル済み" としてマークされます。

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

jobs:
  ...
dependencies:
- ReverseAndOverrideDep_JobParams_UpstreamPipeline:
  reuse: none

    

import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.pipelines.*

object DownsteamPipeline : Pipeline({
    name = "Downsteam pipeline"
        dependencies {
            snapshot(UpstreamPipeline) {
                reuseBuilds = ReuseBuilds.NO
            }
        }
})

    

パイプラインの自動実行

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

新しい変更時

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

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

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

スケジュール時

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

リポジトリ

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

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

リポジトリ URL とソース

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

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

デフォルトブランチとブランチ指定

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

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

プルリクエスト

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

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

構成ファイルのストレージ

パイプラインの YAML 構成の保存場所を指定します: TeamCity サーバー上、またはソースリポジトリ内。これらの設定はメインリポジトリでのみ使用できます。

構成ファイル自体には、YAML (デフォルト) と Kotlin DSL のいずれかのフォーマットを使用できます(パイプライン Kotlin DSL を参照)。親プロジェクトのバージョン管理された設定と、このリポジトリ内/サーバー上の切り替えによって、動作と利用可能なオプションが異なる場合があります。

たとえば、プロジェクトのバージョン管理された設定の同期がオフの場合、そのパイプラインは場所に関係なく設定を YAML に保存します。それ以外の場合、プロジェクトの同期をオンにすると、パイプライン設定はこれらのフォーマットのいずれかになります: YAML 設定をリモートリポジトリにすでに保存している既存のパイプラインはそのまま保存を続けますが、新しいパイプラインとサーバーに設定を保存しているパイプラインは YAML を .kts ファイルに変換します。

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

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

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

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

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

機能ブランチ

パイプラインが YAML 構成をリポジトリに保存している場合、個々のブランチに独自のワークフローを設定できます：

設定エディターで、ブランチセレクターを使用してブランチに切り替えます。
ジョブ、ステップ、パラメーター、または YAML に保存されているその他の設定を編集します。
保存をクリックします。 TeamCity は、そのブランチの YAML ファイルに変更をコミットします。

独自にコミットされた設定がないブランチは、デフォルトブランチの YAML ファイルで定義されたワークフローを継承します。

保護されたブランチ

選択したブランチが保護されている場合、TeamCity は変更を直接コミットできない場合があります。この場合、保存をクリックすると、代わりに保存先として別のブランチを選択するよう求められます。

または、設定エディターのコードビューに切り替え、生成する YAML をコピーし、チームのブランチ保護ルールに従って保護されたブランチに手動でコミットします。

統合

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

パイプライン設定では、ジョブで利用可能な統合の完全なリストを管理します。
ジョブ設定では、トグルを使用して、ジョブが自動的にログインするレジストリを選択し、ビルドステップが必要なデータにアクセスできるようにします。

YAML

パイプラインに直接追加されたインテグレーションは、現在、その設定を YAML に公開します。 YAML で表示されるインテグレーションの唯一の部分は、特定の各ジョブに対して有効化されているインテグレーション ID のリストです。

jobs:
  Job1:
    name: Job 1
    steps:
      - type: script
        name: Run in ECR container
        script-content: |-
          echo "Successfully authenticated and running inside ECR image"
        docker-image: 12345.dkr.ecr.eu-west-1.amazonaws.com/johndoe/my-image:latest
    integrations:
      - AmazonDocker: PROJECT_EXT_112
      - Docker: PROJECT_EXT_30

   

継承された統合

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

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

Amazon ECR

現在、パイプラインとジョブは継承された Amazon ECR 接続のみをサポートしています - パイプライン設定サイドバーまたは YAML から追加することはできません。

親プロジェクトが所有するすべての Amazon ECR 接続は、統合セクションの下に表示されます。個々のジョブには、この特定の接続を使用するかどうかを指定する切り替えが表示されます。

ビルド構成内

従来の TeamCity ビルド構成では、"接続 + ビルド機能" の組み合わせを通じてこの機能がサポートされています：

Docker レジストリ接続ビルド機能は、 Docker Registry と Amazon ECR 接続を使用します。
NPM Registry ビルド機能は、対応する接続を使用します。