TeamCity オンプレミス 2026.1 ヘルプ

ビルド完了トリガの設定

ビルド終了トリガーは、選択したビルド構成のビルドが終了したときに、現在のビルド構成のビルドを開始します。

重要なポイント

  • ビルドトリガーを終了が構成 A に追加されると、ターゲット構成 B を監視し、B が別のビルドを完了するたびに新しい A ビルドを生成します。

  • ターゲット構成のビルドが成功した場合にのみビルドをトリガーするかどうかを選択できます。

  • 完了ビルドトリガーは、同じターゲット構成を指すスナップショット依存関係の恩恵を受けます。

  • ターゲット構成のすべての新しいビルドを追跡する代わりに、ターゲットビルドに新しい変更がある場合にのみ新しいビルドをトリガーすることもできます。これを行うには、代わりにスケジュールトリガーを使用します。

トリガー設定

Finish build trigger settings
  • ビルド構成 — 追跡するビルド構成を選択します。スナップショット依存関係の警告が表示される理由については、トリガーの制限セクションを参照してください。

  • ビルド成功後にのみトリガ — ターゲット構成のビルドが失敗した場合に、新しいビルドのトリガーを回避できます。

  • ブランチフィルター — 特定のブランチのビルドのみを監視できる +|-:<branch_name> 形式のルールセット。詳細については、ブランチフィルターを参照してください。

  • ビルドのカスタマイズカスタムビルドを実行するダイアログと同様のオプションを提供します。詳細については、トリガーされたビルドのカスタマイズセクションを参照してください。

ビルドトリガーとスナップショットの完了

ビルド完了トリガースナップショットの依存関係の違いを理解するために、次の例を見てみましょう。

サンプルプロジェクトには、3 つの子ビルド構成があります。

Chain diagram

この構成は、現在の日付を決定し、それをプロジェクトの product.release.date パラメーターに書き込みます。新しいパラメーターは setParameter サービスメッセージで書き込まれるため、新しい値はこのビルドの範囲内でのみ有効であることに注意してください。

import jetbrains.buildServer.configs.kotlin.* import jetbrains.buildServer.configs.kotlin.buildSteps.csharpScript object UpdateReleaseDate : BuildType({ name = "Update Release Date" steps { csharpScript { id = "csharpScript" content = """ var date = DateTime.Now.ToString("MM.dd.yyyy"); var serviceMessage = "##teamcity[setParameter name='product.release.date' value='" + date + "']"; Console.WriteLine(serviceMessage); """.trimIndent() tool = "%teamcity.tool.TeamCity.csi.DEFAULT%" } } })

この構成は、プロジェクトの build.version パラメーターを増分します。「リリース日の更新」とは異なり、この構成はパラメーター値を永続的に変更するための TeamCity REST API 要求を送信します。

import jetbrains.buildServer.configs.kotlin.* import jetbrains.buildServer.configs.kotlin.buildSteps.script object UpdateBuildVersion : BuildType({ name = "Update Build Version" steps { script { id = "simpleRunner" scriptContent = """ version=%\build.version% ((version=version+1)) curl --location --request PUT 'http://<server_URL>/app/rest/projects/<project_name>/parameters/build.version' \ --header 'Accept: */*' \ --header 'Content-Type: text/plain' \ --header 'Authorization: Bearer your_token' \ --data ${'$'}version """.trimIndent() } } })

この構成はアーティファクトを再公開します。そのためには、まず実際のリリース日とビルド番号が必要であり、これらは他の 2 つの構成から取得されます。

  • 「リリース日の更新」構成に対するスナップショット依存関係が存在するため、更新されたリリース日は dep.<configuration_name>.<parameter_name> 構文を介してアクセスできます。

  • 「ビルドバージョンの更新」構成では REST API を使用して永続的な値を書き込むため、更新されたビルドバージョンはプロジェクトの build.version パラメーターから直接取得されます。

import jetbrains.buildServer.configs.kotlin.* import jetbrains.buildServer.configs.kotlin.buildSteps.script import jetbrains.buildServer.configs.kotlin.triggers.finishBuildTrigger object Delivery : BuildType({ name = "Update Packages" steps { script { id = "simpleRunner" scriptContent = """ echo "Delivery date is ${UpdateReleaseDate.depParamRefs["product.release.date"]}" echo "Build version is %\build.version%" # TODO: Re-publish packages with updated version and date values """.trimIndent() } } triggers { finishBuildTrigger { buildType = "${UpdateBuildVersion.id}" } } dependencies { snapshot(UpdateReleaseDate) { reuseBuilds = ReuseBuilds.NO } } })

この設定で新しいビルドを実行すると、次の結果になります。

  • 新しい「リリース日の更新」ビルドがトリガーされても、他の構成は影響を受けません。ビルドは、どこでも使用されない新しいパラメーター値を計算します。

    Trigger Update Release Date
  • 「ビルドバージョンの更新」構成がトリガーされた場合、このビルドが完了すると、この構成に追加されたビルドトリガーを終了により、新しい「パッケージの更新」構成ビルドが生成されます。ただし、「パッケージの更新」には「リリース日の更新」に対するスナップショット依存関係もあるため ( ビルドの再利用が無効)、現在の日付も要求されます。その結果、「ビルドバージョンの更新→ リリース日の更新→ パッケージの更新」パイプライン全体が実行されます。

    Trigger Update Build Version
  • 新しい「パッケージの更新」ビルドがトリガーされると、まず依存関係の「リリース日の更新」ビルドが実行されます。リリースバージョンは、新しい「リリースバージョンの更新」ビルドを実行せずに、プロジェクトパラメーターから取得されます。

    Trigger Update Packages

その結果、配信ビルドでは常に日付が正しいことが保証されますが、「ビルドバージョンの更新」構成によって新しいビルドが生成されない限り、既存の製品バージョンが再利用されます。ビルドバージョンを増やすと、配信プロセスが自動的にトリガーされます。

トリガーの制限

ビルドトリガーを終了を単独で使用する場合 (同じ構成のスナップショットに依存しない場合)、次の制限があります。

  • 両方の構成に同じ VCS 設定がある場合でも、新しくトリガーされたビルドのリビジョンは、完了した追跡されたビルドと同じではない場合があります。

  • 終了ビルドトリガーを含むビルド構成にターゲットビルド構成へのアーティファクト依存関係がある場合、監視対象ビルドのアーティファクトが使用される保証はありません。これは、トリガーされたビルドがビルドキューに残っている間に、追跡対象構成の別のビルドが終了する可能性があるために発生することがあります。

  • 終了ビルドが別のブランチを使用している場合でも、終了ビルドトリガーによってトリガーされるビルドは、常にデフォルトのブランチでトリガーされます。

  • アルゴリズムは、監視対象の構成で終了したすべてのビルドが、ビルドの終了トリガーを使用して構成内のそれぞれのビルドをトリガーすることを保証しません。たとえば、監視対象の 2 つのビルドがある程度同時に終了した場合、それぞれのビルドが 1 つだけトリガーされる場合があります。この制限と考えられる回避策の詳細については、課題追跡システムの関連タスク(英語)を参照してください。この制限によってビルドパイプラインが制限される場合は、この問題にユースケースを説明するコメントを残してください。

ビルド完了トリガーを含むビルド構成に同じビルド構成へのスナップショット依存関係がある場合、これらすべての制限は適用されません。この場合、トリガーは同じリビジョンでビルドを実行し、ビルドをチェーンにアタッチします。依存関係によって生成された場合は、一貫性のあるアーティファクトも使用します。そのため、対応するスナップショット依存関係が存在しない場合は、ビルド完了トリガー設定ダイアログに警告が表示され、両方の機能を併用することが推奨されます。

ビルド完了トリガーを含むビルド構成に、選択したビルド構成に対するスナップショット依存関係がある場合、トリガーは、最後に監視されたビルドがすでに現在のビルド構成に昇格されているかどうかを検出できます (手動または別のトリガーによって)。この場合、トリガーは新しいビルドを実行しません。

トリガーされたビルドのカスタマイズ

トリガーの設定のビルドのカスタマイズタブでは、このトリガーによって開始されたビルドのカスタムパラメーターを構成できます。カスタムビルドを実行するダイアログと同様に、ビルドパラメーターの値を上書きし、ビルド前にチェックアウトディレクトリをクリーンアップするかどうかを選択できます。

このタブでは、現在のビルド構成で使用されているパラメーターの値をカスタマイズできます。または、新しいパラメーターを追加することもできます。このパラメーターは、このトリガーによって開始されたビルドでのみ使用できます。現在のビルドに他のビルドとのスナップショットの依存関係がある場合、そのようなパラメーターを使用して、依存関係ビルド構成の特定のプロパティをオーバーライドすることもできます。これには reverse.dep.<dependencyBuildID>.<property> 構文を使用します。

トリガー内でビルドパラメーターを再定義してからパラメーターで元のパラメーターを削除すると、その再定義された値がトリガー自体のプレーンテキストパラメーターに変換されることに注意してください。安全な値をカスタマイズするときは、「パスワード」の種類と一緒に保存された場合にのみ隠され、プレーンテキストに変換された場合に読み取り可能になるため、これを考慮することが重要です。

TeamCity を使用すると、同様のタスクを複数の方法で解決できます。場合によっては、異なるビルド構成を作成することが望ましい場合もあります。例: 同じ構成でカスタム実行が多すぎる場合、TeamCity が各ビルドの正確な期間を予測するのが難しい場合があります。多数の異なるパラメーターを使用してビルドをトリガーする必要がある場合は、ビルド構成テンプレートを作成し、それぞれが独自のパラメーターを持つ複数の構成の青写真として使用することをお勧めします。

2025 年 9 月 10 日

関連ページ:

スナップショットの依存関係

ビルド (たとえば、ビルド B) のスナップショット依存関係を別のビルド (ビルド A) のソースに設定することで、ビルド B がビルド A の実行と終了の後にのみ開始されることを保証できます。ビルド A は依存関係ビルドと呼ばれ、ビルド B は依存ビルドと呼ばれます。ビルド設定 | 依存関係ページには、構成された依存関係が表示されます。このページのスナップショットの依存関係セクションでは、ビルドチェーンとその構成をプレビューできます。プレビューにはチェーンのビルドが表示されます。自動トリガーが構...

スケジュールトリガーの設定

スケジュールトリガーを使用すると、特定の構成でビルドを自動的に実行するためのスケジュールを定義できます。1 つのビルド構成に複数のスケジュールトリガーを追加できます。現在のプロジェクト設定のスケジュールを構築するセクションには、構成されたビルド時間が表示されます。トリガー条件:このセクションでは、タイミングや VCS ルールなどのスケジュールトリガーのパラメーターについて説明します。日時定期的なビルドをスケジュールしたり、特定の日時を設定したりできます。特定のタイムゾーンで毎日または毎週の指定...

ブランチフィルター

VCS ルートにブランチが指定されている場合、TeamCity のさまざまな操作でブランチフィルターオプションが使用できるようになります。ブランチフィルターの使用箇所:現在、ブランチフィルターは、次の TeamCity 設定ページで構成できます。ビルド構成のバージョン管理設定ビルド構成に使用できるブランチのセットを制限します。このブランチフィルターは、他のブランチフィルターの前に適用され、カスタムビルドダイアログに表示されるブランチ、およびトリガーとビルドフィーチャーに表示されるブランチを制限...

カスタムビルドの実行

ビルド構成とパイプラインの右上隅には、新しいビルドをトリガーする 2 つのボタンが表示されます。実行 — デフォルト設定で新規ビルドを開始します。カスタムビルドを実行する — ビルド開始前にビルド設定を変更できるダイアログを表示します。この記事では、利用可能なカスタマイズオプションについて説明するとともに、カスタムビルドをトリガーするその他の方法についても触れています。カスタムビルドを実行するダイアログ:このダイアログは、以下のいずれかの場合に TeamCity UI に表示されます。カスタムビル...

ビルドパラメーターの設定

パラメーターは、TeamCity 設定およびビルドスクリプトの構文を介して参照するペアです。パラメーター部分は、生の値 () にすることも、別のパラメーターへの参照 () を含めることもできます。パラメーター型:TeamCity は 3 種類のパラメーターをサポートしています。構成パラメーター — ビルド構成内で設定を共有することを主な目的とするパラメーター。これらのパラメーターを使用して、テンプレートから作成された構成やレシピを使用する構成をカスタマイズすることもできます。TeamCity は...

サービスメッセージ

サービスメッセージは、ビルドに関するコマンド / 情報をビルドスクリプトから TeamCity サーバーに渡す特別に構成されたテキストです。TeamCity、それらはビルドの標準出力ストリームに書き込まれる必要があり、ビルドステップから出力またはエコーされますによって処理されます。例:echo ##teamcity[<messageName> 'value']echo