TeamCity On-Premises 2026.2 Help

Maven

Maven ビルドステップでは、ビルドを自動化するために Apache Maven(英語) を使用できます。

ステップ設定

Maven ステップ設定のリストとそれに対応する UI ラベルは、ビルド構成を構成するかパイプラインを構成するかによって若干異なります。

メイン設定

ゴール

TeamCity に実行させる、スペース区切りの Maven ゴールのリストです。 一部の Maven ゴールはバージョン管理システムを使用できるため、一部の VCS チェックアウトモードゴールと互換性がなくなる可能性があります。

このようなゴールを実行するには、 バージョン管理設定 ページの VCS チェックアウトモード ドロップダウンメニューで「エージェントに自動的に」を選択してください。 これにより、ゴール実行ソフトウェアでバージョン管理システムが利用できるようになります。 Perforce P4 で リリース:準備 ゴールを使用する方法については、 こちらのセクションを参照してください。

作業ディレクトリ

ビルドステップが開始されるディレクトリです。 デフォルトでは、エージェントがリモートソースをチェックアウトするルートディレクトリと同じです。 詳細については、次のトピックを参照してください: ビルド作業ディレクトリ

詳細設定

POM の場所

ビルドチェックアウトディレクトリを基準とした POM ファイルへのパス。 デフォルトでは pom.xml になります。

ランナーの引数

コマンドラインパラメーターのリスト。

Maven バージョン

使用する Maven のバージョンを選択します。 インストールされているバージョンを管理することもできます。

  • <自動> — Maven インストールへのパスは M2_HOME 環境変数から取得されます。取得できない場合は、現在のデフォルトバージョンが使用されます。

  • <デフォルト> — バンドルされているバージョンがデフォルトとして使用されます。 デフォルトの変更方法については、こちらを参照してください。

  • <カスタム> — カスタム Maven バージョンへのパスを指定します。

ビルド構成設定

これらの設定は、 ビルド構成内で使用される Maven ステップでのみ使用できます。

ユーザー設定の選択

様々な種類のユーザー設定を選択できます。 この設定は、 -s または --設定 コマンドライン引数を追加するのと同じです。 使用可能なオプションは以下のとおりです。

  • <デフォルト> — エージェント上のデフォルトの Maven の場所からユーザー設定をインポートします。 参照: Maven サーバー側設定

  • <カスタム> — 代替ユーザー設定ファイルへのパスを指定できます。 パスはエージェントと サーバーの両方で有効である必要があります。

  • 定義済み設定 — プロジェクト設定 | Maven 設定 ページで TeamCity サーバーにアップロードされた設定ファイルから 1 つを選択できます。 アップロードされたファイルは、現在のプロジェクトとそのすべてのサブプロジェクトの両方で使用でき、 <TeamCity データディレクトリ>/config/projects/%projectID%/pluginData/mavenSettings ディレクトリに保存されます。 アップロードされたファイルは、エージェント側とサーバー側の Maven 機能の両方で使用されます。

カスタム設定または定義済み設定を使用する場合、有効なユーザー設定ファイルへのパスは、maven プロセス内で TeamCity Maven ユーザー設定パス システムプロパティとして使用できます。

アーティファクトリポジトリ

次のいずれかのローカルアーティファクトリポジトリオプションを選択できます。

  • エージェントごと (デフォルト) - エージェントによって実行されるすべてのビルドによって生成されたアーティファクトを、エージェントシステムディレクトリに別個のリポジトリを使用して保存します。

  • ビルド構成ごと - 現在のビルド構成のすべてのビルドによって生成されたアーティファクトを保存するには、別のリポジトリを使用します。

  • Maven デフォルト — デフォルトの Maven リポジトリの場所を使用します。 リポジトリは、すべてのビルド構成とマシン上のすべてのエージェント間で共有されます。

    このモードでは、Maven ステップは追加のコマンドラインパラメーター Maven ローカルリポジトリ で指定された場所を使用します。 このパラメーターが指定されていない場合は、 settings.xml で設定された値を検索します。

インクリメンタルビルド

増分ビルドの一般的な考え方は、変更されたモジュールのみを処理し、それらと接続された変更されていないモジュールの再処理に時間を費やさないことです。 TeamCity はこのメソッドを使用して、変更された Maven モジュールに対してのみテストを実行し、ビルドまたはビルドチェーンを再実行するときの時間を節約します。

Maven 自体ではインクリメンタルビルドのサポートが非常に限られているため、TeamCity は独自の変更影響分析アルゴリズムを使用して影響を受けるモジュールの設定を決定し、影響を受けるモジュールの依存関係を作成するために特別な予備フェーズを使用します。

まず TeamCity は、親関係と異なる依存関係スコープを考慮して独自の変更影響分析を実行し、影響を受けるモジュールを特定します。 次に、ビルドは 2 つの連続した Maven 実行に分割されます。

準備フェーズと呼ばれる最初の Maven の実行は、影響を受けるモジュールの依存関係を構築することを目的としています。 準備段階では、依存関係クラスが存在しないか矛盾していることが原因で、2 回目の実行時にコンパイラーやその他のエラーが発生しないようにします。

メインフェーズと呼ばれる 2 回目の Maven の実行では、メインゴール(たとえば テスト )が実行されるため、変更の影響を受けるテストのみが実行されます。

また、このトピックに関連する ブログ投稿(英語)を確認してください。

コンテナー設定

このビルドステップは、Docker または Podman によってデプロイされたコンテナー内で実行できます。

クラシックビルド構成ステップでは、イメージ名、プラットフォーム、追加の実行引数を指定できる一連のプロパティが表示されます。 イメージを明示的にプルにより、このステップが実行されるたびに TeamCity がターゲットコンテナーからイメージを確実にプルします。

Dk docker container settings

指定されたイメージを検索するレジストリを TeamCity に指定するには、プロジェクトに Docker/Podman 接続を追加します。 デフォルトでは、この接続により TeamCity は Docker Hub から匿名モードでイメージをプルできますが、任意のコンテナーレジストリ向けに設定できます。

詳細については、次の記事を参照してください: コンテナーラッパー

コンテナー内でステップを実行するには、 Docker で実行をオンに切り替えます。 有効にすると、この要素に 2 つのオプションが表示されます。

コンテナー内でパイプラインステップを実行
  • Docker イメージ — Docker または Podman レジストリからイメージをプルできます。 デフォルトでは、TeamCity は Docker Hub イメージを匿名モードでプルできます。 その他の場合 (プライベートイメージ、カスタムイメージレジストリ、Docker Hub のレート制限に違反しないようにする非匿名モード) は、パイプラインまたはジョブレベルで Docker 統合を構成します。

  • Dockerfile — Dockerfile からカスタムイメージをビルドできます。

    Java パラメーター

    JDK

    JDK を選択してください。 このセクションは利用可能なオプションを詳しく述べています。 デフォルトは JAVA_HOME 環境変数またはエージェント自身の Java です。

    JDK ホームパス

    上で <カスタム> が選択されている場合に、このオプションを使用できます。 このフィールドを使用して、ビルドの実行に使用するカスタム JDK へのパスを指定します。 フィールドが空白の場合、JDK Home へのパスは、エージェントマシン上の JAVA_HOME 環境変数、または ビルドエージェント構成ファイル (ビルドエージェント.プロパティ) で指定された env.JAVA_HOME 環境変数 プロパティから読み取られます。 これらの値が指定されていない場合、TeamCity はビルドエージェントプロセス自体の Java ホームを使用します。

    JVM コマンドラインパラメーター

    追加の JVM コマンドラインパラメーターを使用すると、初期および最大ヒープサイズの設定、追加のログの有効化、必要なバイトコード検証モードの選択などを行うことができます。

    標準 (- で始まる、たとえば -verbose:[class|module|gc|jni] または --dry-run) と非標準 (-X で始まる、たとえば -Xmx<サイズ> または -XstartOnFirstThread) の両方の JVM オプションを指定できます。

    複数のコマンドラインパラメーターを指定するには、区切り文字としてスペースを使用します。 例:

    -verbose:gc -Xdiag -Xcomp -Xmx512m -Xms256m

    コードカバレッジ

    Maven ビルドランナーは、IDEA カバレッジエンジンに基づくコードカバレッジをサポートします。 コードカバレッジオプションの構成について詳しく見るには、 Java コードカバレッジの構成 ページを参照してください。

    同じマシンに複数のビルドエージェントがインストールされている場合、デフォルトではそれらは同じローカルリポジトリを使用します。 ただし、各ローカルエージェントにカスタムローカルリポジトリを割り当てる方法は 2 つあります。

    • teamcity-agent/conf/buildAgent.プロパティ で次のプロパティを指定します。

      system.maven.repo.local=%\system.agent.work.dir%/<subdirectory_name>

      たとえば、 %system.agent.work.dir%/m2-リポジトリ です。

    • 各ビルドエージェントを異なるユーザーアカウントで実行します。

    異なる VCS での Maven リリース

    TeamCity がサポートする異なる VCS で リリース:準備 Maven タスクを実行するには、 Maven リリースプラグインのバージョン 2.0 以上を使用していることを確認してください。

    Perforce での Maven リリースの使用

    Maven リリースプラグインには、Perforce で認証 するためのチケットが必要(英語)です。

    TeamCity のビルド構成の Perforce VCS ルート設定では:

    1. エージェントでチェックアウトを有効にします。

    2. Perforce VCS ルート設定で チケットベースの認証を使用するを有効にします。

    3. ビルドエージェント環境に、Maven Release Plugin の実行を妨げる可能性のある時折の P4 変数がないことを確認してください。

    4. Maven ビルドステップの ゴールフィールドに リリース:準備 を指定してビルドを実行します。

    Git VCS での Maven リリースの使用

    このプラグインを Git で使用するには、 pom.xml で Git SSHURL を SCM の URL(英語) として設定します。

    TeamCity エージェントで:

    1. エージェントに Git がインストールされ、Unix ライクな OS ではエージェントの $PATH に、Windows では %PATH% 環境変数に追加されていることを確認してください。

    2. エージェントで、次を実行してアカウントの ID を設定します

      git config --system user.email "buildserver@example.com" git config --system user.name "TeamCity Server"
    3. Git VCS がエージェントの既知のホストデータベースに追加されていることを確認してください。

    TeamCity サーバーで:

    1. Git SSH 鍵を TeamCity サーバーにアップロードします。

    2. 構成設定を開き、 バージョン管理設定 設定タブに移動します。

    3. エージェントでチェックアウトを有効にします。

    4. Git VCS ルートで、 秘密鍵認証を有効にします。

    5. SSH Agentビルド機能を構成に追加します。

    6. Maven ビルドステップの ゴール フィールドに リリース:準備 を指定してビルドを実行します。

    リモート実行の制限

    Maven ランナーに関連するリモート実行制限:

    ルール上、TeamCity の個人用ビルドは、TeamCity サーバー上で実行される "通常" のビルドには影響せず、その結果は開始者にのみ表示されます。 ただし、Maven ランナーを使用する場合は動作が異なる場合があります。

    TeamCity は Maven 依存関係モデルに一切干渉しません。 そのため、Maven 構成がアーティファクトをリモートリポジトリにデプロイする場合は、 個人用ビルドを実行しても、そこにデプロイされます。 そのため、個人用ビルドは構成に依存するビルドに影響する場合があります。
    たとえば、アーティファクトをリモートリポジトリにデプロイする構成 A があり、これらのアーティファクトが構成 B で使用されているとします。 A の個人用ビルドが完了すると、個人用アーティファクトが B に表示されます。 構成 A がリリースバージョンのアーティファクトを生成する場合、これは特に有害になる可能性があります。正しいアーティファクトが開発者のものに置き換えられ、Maven のバージョニングモデルのため調査が難しくなるためです。 さらに、これらのアーティファクトは、TeamCity で管理されるものだけでなく、すべての依存ビルドで利用可能になります。
    これを避けるため、アーティファクトのデプロイを行うビルド構成ではリモート実行を使用しないことをお勧めします。

    コードとしての構成

    次のスニペットは、 YAML (パイプラインのみ) と Kotlin DSL の両方の形式でカスタマイズされたビルドステップを示しています。

    object Build : BuildType({ name = "Build" steps { maven { goals = "clean test" runnerArgs = "-Dmaven.test.failure.ignore=true" mavenVersion = bundled_3_8() jdkHome = "%env.JDK_21_0%" jvmArgs = "-verbose:gc -Xdiag -Xcomp -Xmn54m" } } })

    MavenBuildStep Kotlin DSL ドキュメント(英語)も参照してください。

    jobs: Job1: name: Maven Project steps: - type: maven maven-version: bundled_3_6 pom-location: pom.xml goals: '-B -DskipTests clean package' jdk-home: '%env.JDK_21_0%' name: MavenCleanPackage runner-arguments: '-Dmaven.test.failure.ignore=true'
    2026 年 9 月 11 日