ジョブ設定

ジョブ設定の編集

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

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

依存関係

このセクションでは、スタンドアロンジョブを統一されたワークフローに配置できます。 ビジュアルエディターでも同じ操作を行えます。ジョブの端にカーソルを合わせてプラスアイコンを表示し、接続先のジョブのどちらかの側にドラッグします。

上流ジョブへの依存関係を追加する場合は、次も設定できます：

• 共有ファイルを無視する — 有効化すると、ジョブはアップストリームジョブが 共有するファイルを自動的にダウンロードしません。 アップストリームジョブがファイルを共有している場合にのみ利用できます。

• 上流が失敗してもジョブを実行 — デフォルトでは、アップストリームジョブが失敗すると、それに直接または間接的に依存するすべてのジョブがキューから削除され、"依存先のビルドの一部が失敗しました" エラーでキャンセルされます。 特定の依存関係でこのオプションを有効化すると、その特定のアップストリームジョブが失敗してもジョブを実行できます。ただし、パイプラインの実行全体は引き続き失敗としてマークされます。 たとえば、クリーンアップジョブや通知ジョブを常に実行するために使用します。

ステップ

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

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

ビルド機能

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

例:

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

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

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

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

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

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

ビルドキャッシング

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

詳細: ビルドキャッシング

空きディスク容量

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

詳細: 空きディスク容量

XML レポート処理

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

詳細: XML レポート処理

最適化

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

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

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

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

  

  上部の "Optimization" タイルに注目してください: TeamCity はこの実行を前回よりほぼ五倍速く完了し、再利用された実行によって前回の実行時間のほぼ 80% が節約されました。

エージェント要件

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

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

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

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

独自の要件を定義するには、 カスタム要件を追加 をクリックします。 各要件は <agent.parameter> <演算子> [値] 式です。 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。

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

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

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

演算子

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

関連事項: 要件条件

値

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

次の YAML サンプルでは、三つの要件を定義しています: RAM 16 GB、10 GB 以上の空きディスク容量、Python 3 がインストールされていること。 標準の TeamCity 要件では短い エイリアス: 値 構文を使用し、カスタム要件では完全な <パラメーター> <演算子> [値] 式を使用します (公開タイトル用の追加の お名前 パラメーターを含む)。

パラメーター

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

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

• ジョブパラメーター は通常、親ジョブ内でのみ使用できます。 デフォルトでは、 環境。 接頭辞が含まれます。 ダウンストリーム ジョブからジョブパラメーターにアクセスするには、 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'

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

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

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

出力ファイル

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

アーティファクト

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

アーティファクトは次の 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 つのファイルを生成するジョブを示しています。

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

リポジトリ

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

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

リポジトリ セクション項目の対応するオプションを使用して、チェックアウトされたソースのカスタムディレクトリを指定できます。 チェックアウトディレクトリへのパスは絶対パスにできますが、相対パス (マイカスタムフォルダー) または定義済みの TeamCity パラメーターを参照するパス (%\teamcity.エージェント.作業.ディレクトリ%/マイカスタムフォルダー) のいずれかを使用することを強くお勧めします。

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

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

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

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

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

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

統合

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

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

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

すべての情報については、 パイプライン連携セクションを参照してください。