ビルドチェーンの作成
このチュートリアルでは、前回の 最初のビルドを構成して実行する チュートリアルで作成したパイプラインと連携して動作する、別のパイプラインを作成する方法を説明します。
このチュートリアルで取り上げるトピック:
パイプラインの依存関係とビルドチェーン
Docker イメージをビルド
ジョブエージェントの要件
エージェントターミナルを構築します
上流のチェーンビルドを再利用
作品の出版と交換
基本概念ぴったり一致しました。
TeamCity では、単独のエンティティを 1 つのワークフローにリンクする主なメソッドが二つあります。
- ビルドチェーン
ビルドチェーン とは、相互接続されたビルド構成とパイプラインのシーケンスのことです。
これらの独立したオブジェクト間の関係は、右から左、つまり下流から上流の順に設定されます。 例: 2 つのパイプラインを「パイプライン A →パイプライン B」の順序で実行するには、「パイプライン B」に「パイプライン A」への依存関係を追加します。 つまり、TeamCity に "B" が "A" に依存していることを伝えます。
これには 2 つの効果があります。
「パイプライン A」には依存関係がなく、単独で実行できます。 「パイプライン A」を実行しても「パイプライン B」は起動しません。
「パイプライン B」は「パイプライン A」に依存しているため、単独では実行できません。 「B」をトリガーするには、「A」の実行が完了している必要があります。 チェーン設定に応じて、TeamCity は新しい "Pipeline A" の実行を開始して完了を待つか、以前に成功した "Pipeline A" の実行結果を再利用して "B" をすぐに開始します。
- ビルド完了トリガー
ビルドトリガーを終了するは、ビルド依存関係チェーンの反対です。 ビルド構成間で左から右への関係を作成できます (パイプラインは現在サポートされていません)。 この場合、上流の「Config A」をトリガーすると、「Config A → Config B」シーケンスが実行されます。 完了すると、下流の「Config B」が自動的にトリガーされます。 この設定では、「Config B」は外部ビルドをトリガーすることなく単独で実行できます。
完成ビルドトリガーは、主に通常のビルドチェーンと組み合わせて使用されます。
TeamCity エンティティ間の関係を作成するさまざまな方法について詳しくは、次のセクションを参照してください: 依存関係をセットアップする。
ステップ 1: パイプラインを作成する
前のチュートリアルで作成したパイプラインを所有するプロジェクトの 一般 設定に移動します。
パイプラインを作成 をクリックします。
すでに GitHub から必要なプロジェクトをチェックアウトするパイプラインが設定されているため、 既存の VCS ルートから オプションを選択できます。 これにより、リポジトリへのアクセスに必要なすべての設定を即座に再利用できます。
./docker/Dockerfileを使用して Docker イメージをビルドする スクリプトビルドステップを追加します。 ビルドステップの設定方法や YAML エディターの使用方法がわからない場合は、 前のパートを参照してください。jobs: Job1: name: Docker build steps: - type: script script-content: docker build -f ./docker/Dockerfile -t johndoe/myapp:%build.number% .このジョブはイメージを作成するため、 Docker またはポッドマンがインストールされているビルドエージェントで実行する必要があります。 必要なツールがないビルドエージェントに割り当てられないようにするには、 エージェント要件を追加し、さらに別の 事前定義済み TeamCity パラメーターである
コンテナー.エンジンを使用します。jobs: Job1: ... runs-on: self-hosted: - requirement: exists name: ImageBuilderTool parameter: container.engineパイプラインを実行し、正常に完了することを確認してください。 エージェントターミナルで
docker image lsを実行すると、イメージが正しく構築されたことを確認できます。
ステップ 2: ビルドチェーンを構成する
これで、アプリのビルドとテストを行うパイプラインと、Docker イメージを生成するパイプラインの 2 つが別々に用意されました。 これらを接続するには、ビルドチェーンを作成します。
Docker パイプラインは、アプリのビルドとテストが完了した後にのみイメージが生成されるべきであるため、下流に配置する必要があります。 チェーンの依存関係は 右から左（下流のオブジェクトが所有し、上流のオブジェクトを指す）に構成されるため、Docker パイプラインに依存関係を追加する必要があります。
Docker パイプラインの設定を開き、パイプラインを選択して、個々のジョブ設定ではなくパイプ ラインの設定を表示します。
追加 をクリックします (パイプラインの依存関係 セクションの横)。
依存先 リストから別のパイプラインを選択し、 完了 をクリックしてください。
両方のパイプラインで、 ジョブ設定 | 最適化 | ジョブ結果の再利用 のすべてのオプションを無効にします。 実際のワークフローでは、これらの最適化の一部を有効にしたままにしておくことが多いでしょうが、今回は再利用ロジックのレイヤーを追加することなく依存関係の設定に集中するため、これらのオプションを無効にします。
Docker ビルド構成を実行してください。 両方のパイプラインが実行されているはずです。 Docker パイプラインの実行結果ページの チェーン タブに切り替えると、チェーンの各セクションに関する詳細情報（ビルド番号、実行時間など）が表示されます。
Docker パイプラインを再実行します。 ステップ #3 で構成したパイプライン依存関係で 適切なものがあれば、新しいビルドを実行しないでください が有効化されているため、TeamCity はアップストリームパイプラインの前回の実行を再利用し、Docker パイプラインだけを再度実行します。
これは チェーン タブで確認できます。アップストリームパイプラインのビルド番号は同じままになっているはずです。
最初のビルド / テストパイプラインを実行してください。 このパイプラインは単独で実行され、Docker パイプラインはトリガーされないことに注意してください。
Docker パイプラインの設定を開き、既存の依存関係を編集します。 新しいビルドを実行しない… の設定を無効にします。
Docker パイプラインを数回実行してください。 再利用設定がオフになっているため、毎回両方のパイプラインが新たに開始されるはずです。
ステップ 3: アーティファクトを公開して交換する
ステップ 1 では、 file '/build/libs/todo.jar' not found エラーが発生した可能性があります。 このエラーを再現するには、2 つのパイプラインを別々のエージェントで実行し、両方の {agent_home}/work ディレクトリをクリアしてクリーンな環境を確保してください。
このエラーが発生する理由は以下のとおりです。
Dockerfile は
./build/libs/todo.jarをイメージにコピーします。このファイルは、親ディレクトリとともにビルドフェーズ中に生成され、リポジトリには保存されません。
Docker パイプラインを実行するエージェントは、リモートソースをチェックアウトし、
docker ビルドを実行します。 最初にgradle クリーンビルドを実行していないため、期待されるtodo.jarファイルが見つかりません。
この問題を解決するには、ビルド / テストパイプラインによって生成された ./build/libs/todo.jar をチェーンに渡す必要があります。
上流のビルド / テストパイプラインの設定を開き、ビルドジョブを選択します。
出力ファイル設定セクションで、 共用ファイル と アーティファクト の両方のチェックボックスを選択した状態で
./build/libs/todo.jarファイルを追加します。jobs: Job1: name: Job 1 steps: - type: gradle name: Build app tasks: clean build jdk-home: '%env.JDK_11_0_ARM64%' dependencies: - Job2 - Job3 allow-reuse: false runs-on: self-hosted: - requirement: equals name: Agent name parameter: system.agent.name value: macOS J21 files-publication: - path: ./build/libs/todo.jar share-with-jobs: true publish-artifact: true ...このビルドを実行し、ターゲットファイルが アーティファクト タブに公開されていることを確認してください。 十分な権限を持つ TeamCity ユーザーは、ビルド結果ページから公開済みアーティファクトをダウンロードできます。
共用ファイル チェックボックスをオンにすると、ファイルは下流のジョブで使用できるようになりますが、同じパイプライン内でのみ使用可能です。 チェーンの下流にある外部パイプラインや構成では、共有ファイルは自動的にインポートされないため、手動でインポートする必要があります。
クラシックビルド構成では、 アーティファクト依存関係を宣言することで、これを行えます。これは、二つのパイプラインをリンクするために使用したパイプライン依存関係と同様に機能します。 パイプラインでは、アーティファクト依存関係はまだ完全にはサポートされておらず、YAML 構成ファイルを編集することでのみ追加できます。
jobs: Job1: name: Docker build steps: - type: script script-content: docker build -f ./docker/Dockerfile -t johndoe/myapp:%build.number% . ... download-artifacts: - GSFirstBuild_GradleDockerPipelineTeamCitySamples: # same ID as in 'dependencies' block from: dependency artifact-rules: todo.jar=>./build/libs clean-destination: true dependencies: - GSFirstBuild_GradleDockerPipelineTeamCitySamples: reuse: noneビルドチェーンを実行し、各パイプラインが別々のエージェントで処理される場合でも、ビルドが正常に完了することを確認してください。