ジョブ設定

ジョブ設定の編集

ジョブ設定を表示および編集するには、右上隅の設定トグルをクリックし、任意のジョブタイルをクリックします (または、新しいジョブを作成するには追加タイルをクリックします)。

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

ステップ

このセクションを使用して、プロジェクトのビルドとテスト、カスタムスクリプトの実行、Docker イメージのアップロードなど、ジョブの実行内容を定義します。

現在、パイプラインは 4 種類のステップを追加できます。これらはすべて、対応する従来のビルド構成ステップの軽量版です。

機能を構築する

ビルド機能も、ステップと同様に特定の動作を実行します。ただし、機能はビルドライフサイクルのあらかじめ定義されたタイミングで実行されるのに対し、ステップはより柔軟性があり、必要に応じて配置できます。

例:

• スクリプトは、ターミナルコマンドを実行するビルドステップです。その動作は設定によって異なり、単一のコマンドまたは完全なスクリプトを実行したり、インラインスクリプトまたはファイルベースのスクリプトを使用したり、パイプラインの任意の場所で実行したりできます。

• Swabra は、ビルド機能の一つで、ビルド中に生成されたファイルをクリーンアップするという特定のアクションを、ビルドの前または後のいずれかの特定のタイミングで実行します。

現時点では、パイプラインはビルド構成で利用可能なビルド機能のごく一部のみをサポートしています。

ビルドファイルをきれいにする (Swabra)

ビルド中に作成、変更、削除されたファイルを追跡します。新規ファイルはビルド完了時または次回のビルド開始時に削除され、変更および削除されたファイルはビルドログに記録されます。追跡対象を特定のファイルやディレクトリに限定することも可能です。

詳細: ビルドファイルクリーナー (Swabra)

キャッシュを構築

ダウンロードした npm パッケージや Maven ローカルリポジトリアーティファクト(英語)など、以前の実行時に生成されたファイルを再利用することで、ビルドパフォーマンスが向上します。

詳細: ビルドキャッシュ

空きディスク容量

エージェントディスクを自動的にクリーンアップし、新しいビルドに必要な空き容量を確保します。

詳細: 空きディスク容量

XML レポート処理

TeamCity では、外部ツールによって生成されたレポートファイルを使用できます。サポートされている形式には、JUnit、Surefire/Failsafe、TRX、Google Test などのテストフレームワークのレポート、および SpotBugs、PMD、Checkstyle などのツールによるコード分析レポートが含まれます。

詳細: XML レポート処理

最適化

このセクションでは、パイプラインの実行を大幅に高速化し、時間とリソースを節約し、クラウドエージェントの場合はインフラストラクチャコストを節約するための設定について説明します。

• 並列テスト — Maven および Gradle ステップにより、テストスイートをバッチに分割し、個別のビルドエージェントで並列に実行される N 個の仮想ビルドを生成できます。

• ジョブ結果の再利用 — 有効なリポジトリに新しい変更が含まれていない場合、TeamCity はジョブの再実行をスキップし、前回の実行からアーティファクト、ステータス、結果を再利用します。これにより、最近の変更の影響を受けるジョブのみが実行されます。

  混乱を避けるために、再利用されたジョブは UI で明示的にマークされます。

  

  上部の「最適化」タイルに注目してください。TeamCity はこの実行を前回よりも 5 倍近く速く完了し、実行の再利用によって前回の実行時間の約 80% が節約されました。

エージェント要件

TeamCity はエージェントソフトウェアを自動的に追跡し、キューに入れられた実行が互換性のあるエージェントにのみ割り当てられるようにします。例: Maven ステップをコンテナーで実行する必要がある場合、Docker または Podman のないエージェントは互換性がないとしてマークされます。

同様に、ジョブがプロジェクト、パイプライン、ジョブのいずれのセクションにも定義されていないパラメーターを使用する場合、TeamCity は、このパラメーター値の最後の潜在的なソースとしてエージェントマシンをチェックします。例: コマンドラインステップで echo %myParam% が未知のパラメーター参照で実行される場合、空でない「myParam」パラメーターを持つエージェントのみがジョブを実行できます。

エージェントの要件セクションでは、名前、ハードウェアスペック、インストールされているツールなど、対象エージェントの追加条件を定義できます。

TeamCity は、CPU コアの数、エージェントメモリの合計量、CPU アーキテクチャなど、ほとんどの基本的なエージェントハードウェア要件についてすぐに使用できるオプションを表示します。

独自の要件を定義するには、カスタム要件を追加するをクリックします。各要件は <agent.parameter> <operator> [value] 式です。TeamCity は、承認されたエージェントごとにこれらの式を評価し、「true」を返すエージェントをジョブの実行対象としてマークし、それ以外のエージェントを非対応としてマークします。

エージェントパラメーター

エージェントマシンによって報告されるパラメーターで、その値は必要な基準に一致する必要があります。以下に、様々なエージェントパラメーターの例をいくつか示します。

• teamcity.agent.jvm.os.arch — エージェントマシンのアーキテクチャを報告します。例: Apple ARM デバイスで実行されている macOS エージェントの場合は aarch64 です。

• env.ANDROID_SDK_HOME — エージェントマシンにインストールされている Android SDK へのパスを返します。例: /home/builduser/android-sdk-linux

• teamcity.agent.jvm.user.timezone — エージェントマシンのタイムゾーンを格納します。例: Etc/UTC

• MonoVersion — Mono プラットフォームのバージョンを返します。例: 6.12.0.200

エージェント | <TeamCity_ エージェント> | エージェントパラメータータブに移動して、エージェントが報告するパラメーターを確認し、エージェントのハードウェアおよびソフトウェアデータを保存するパラメーターを見つけます。

事前定義されたビルドパラメーターのリストも参照してください。

演算子

実際のエージェントパラメーター値と指定された値を比較するために使用される論理演算子。例: 「より小さい」、「で始まる」、「含む」など。

関連事項: 要件条件

値

エージェントのパラメーター値と比較するカスタム値。値を必要としない唯一の演算子は exists です。この演算子は、エージェントが実際の値に関係なく、必要なパラメーターを報告しているかどうかを確認します。

以下の YAML サンプルでは、3 つの要件を定義しています。16 GB の RAM、10 GB 以上のディスク空き容量、Python 3 のインストールです。標準の TeamCity 要件では短縮された alias: value 構文を使用し、カスタム要件では完全な <parameter> <operator> [value] 構文（公開タイトル用の name パラメーターを追加）を使用します。

パラメーター

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

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

• ジョブパラメーターは通常、親ジョブ内でのみ使用できます。デフォルトでは、env. 接頭辞が含まれます。ダウンストリームジョブからジョブパラメーターにアクセスするには、job.<source_job_ID>.<parameter_name> 構文を使用します。以下のサンプルは、単一のパラメーターを持つジョブを示しています。ダウンストリームジョブは、このパラメーターへの参照を使用して、独自の ParamJobB を指定します。

  jobs: Job1: name: Job 1 steps: - type: script script-content: |- echo "Print Job1 parameter: %env.ParamJobA%" # prints 'foo' parameters: env.ParamJobA: foo Job2: name: Job 2 dependencies: - Job1 parameters: env.ParamJobB: '%job.Job1.env.ParamJobA% bar' steps: - type: script script-content: |- echo "Print parameter from upstream Job: %job.Job1.env.ParamJobA%" # prints 'foo' echo "Print modified parameter: %env.ParamJobB%" # prints 'foo bar'

• パイプライン入力パラメーターは、このパイプラインのすべてのジョブで共有されます。詳細については、パイプラインパラメーターを参照してください。

• パイプライン出力パラメーターは同一パイプライン内では使用できません。代わりに、同じチェーンに属する下流のパイプラインおよび構成に渡されます。詳細については、パイプラインの依存関係を参照してください。

ジョブステップでは、 setParameter サービスメッセージメッセージを送信してパラメーター値を動的に編集したり（または新しいパラメーターを作成したり）することもできます。ただし、変更された値は、このメッセージを送信したステップが完了した後にのみ使用可能になることに注意してください。

出力ファイル

ジョブによって共有されるファイルは、アーティファクト、下流のジョブの内部ファイル、その両方として機能します。

アーティファクト

アーティファクトは、実行結果ページのアーティファクトタブに表示されるファイルです。プロジェクトの表示権限を持つユーザーは、これらのファイルをローカルストレージにダウンロードできます。

アーティファクトは次の 2 つの方法で表示できます。

• 実行結果ページで、アーティファクトタブを開いて、パイプラインのジョブによって公開されたすべてのアーティファクトを表示します。

• 同じページからジョブを選択してサイドパネルを開き、アーティファクトタブに切り替えて、その特定のジョブによって生成されたアーティファクトを表示します。

共用ファイル

共有ファイルはパイプラインを通じて後続のジョブに渡されます。これらは通常、内部ファイルまたはまだ確定していないファイルです。

アーティファクトとは異なり、共有ファイルはビルド結果ページのメインのアーティファクトタブには表示されません。ただし、ジョブサイドパネルのアーティファクトタブには、隠しファイルである .shared_files.zip アーカイブに圧縮されて表示されます。

以下の YAML の例では、ファイルを作成および変更するジョブと、ファイルをインポートしてその内容を出力するジョブが示されています。「ジョブ 2」は、ファイルをアーティファクトとして公開します。

jobs: Job1: name: Create file steps: - type: script script-content: |- touch sample.txt echo "File created by Job 1, build #%tc.build.number%" >> sample.txt files-publication: - path: sample.txt share-with-jobs: true publish-artifact: false Job2: name: Print file contents dependencies: - Job1 steps: - type: script script-content: cat sample.txt files-publication: - path: sample.txt share-with-jobs: false publish-artifact: true

これら 2 つのタイプは相互に排他的ではありません。出力ファイルを追加するときに、共用ファイルとアーティファクトの両方のチェックボックスをオンにすることができます。

共有ファイルは親ディレクトリ階層を保持しますが、アーティファクトは保持されないことに注意してください。次のサンプルは、関連するフォルダーに 2 つのファイルを生成するジョブを示しています。

ほぼ同じステップスクリプトと files-publication ルールを使用しているにもかかわらず、結果はわずかに異なります。共有ファイルは親フォルダーと共に隠しアーカイブ「.shared_files.zip」に配置されますが、アーティファクトはそのまま「publish」ディレクトリ以下にまとめられます。

リポジトリ

このセクションでは、このジョブがチェックアウトするリモートリポジトリを選択できます。リポジトリを追加するには、パイプライン設定のリポジトリセクションに新しいエントリを作成してください。

デフォルトでは、ソースはエージェントの作業ディレクトリのサブフォルダーにチェックインされます。エージェントが別のジョブを実行する際に、あるジョブのソースが常に失われないようにするため、このサブフォルダーにはジョブごとに一意の名前（例: /mnt/agent/work/6fa95896c6cadf54）が自動生成されます。

リポジトリセクション項目の対応するオプションを使用して、チェックアウトされたソースのカスタムディレクトリを指定できます。チェックアウトディレクトリへのパスは絶対パスでも構いませんが、相対パス（MyCustomFolder）または定義済みの TeamCity パラメーターを参照するパス（%teamcity.agent.work.dir%/MyCustomFolder）を使用することを強くお勧めします。

以下のダイアグラムは、ビルドプロセスに関係するコアディレクトリ間の関係の概要を示しています。

詳細については、次の記事を参照してください。

• エージェントホームディレクトリ — ビルドエージェントのインストールディレクトリ。

• エージェント作業ディレクトリ — ビルド関連のファイルを保存するエージェントホームディレクトリのサブフォルダー。

• ビルドチェックアウトディレクトリ — チェックアウトされたすべてのソースがダウンロードされるエージェント作業ディレクトリのサブフォルダー。

• 作業ディレクトリを構築する — ビルドステップが開始されるディレクトリ (デフォルトでは「ビルドチェックアウトディレクトリ」と同じです)。

統合

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

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

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

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

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

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

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

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