ビルド完了トリガーの設定

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

鍵となるポイント

ビルド完了トリガーが構成 A に追加されると、ターゲット構成 B を監視し、B が別のビルドを完了するたびに新しい A ビルドを生成します。
ターゲット構成のビルドが成功した場合にのみビルドをトリガーするかどうかを選択できます。
完了ビルドトリガーは、同じターゲット構成を指すスナップショット依存関係の恩恵を受けます。
ターゲット構成のすべての新しいビルドを追跡する代わりに、ターゲットビルドに新しい変更がある場合にのみ新しいビルドをトリガーすることもできます。これを行うには、代わりにスケジュールトリガーを使用します。

トリガー設定

ビルド構成 — 追跡するビルド構成を選択します。スナップショット依存関係の警告が表示される理由については、トリガーの制限セクションを参照してください。
成功したビルド後にのみトリガー — ターゲット構成のビルドが失敗した場合に、新しいビルドのトリガーを回避できます。
ブランチフィルター — 特定のブランチのビルドのみを監視できる +|-:<ブランチ名> 形式のルールセット。詳細については、ブランチフィルターを参照してください。
ビルドのカスタマイズ — カスタムビルドを実行するダイアログと同様のオプションを提供します。詳細については、トリガーされたビルドのカスタマイズセクションを参照してください。

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

ビルド完了トリガーとチェーン依存関係の構成の違いを理解するために、次の例を見てみましょう。

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

この構成は、現在の日付を決定し、それをプロジェクトの 製品.リリース.日付 パラメーターに書き込みます。新しいパラメーターは パラメーターを設定 サービスメッセージで書き込まれるため、新しい値はこのビルドのスコープ内でのみ有効です。

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%"
        }
    }
})

       

この構成は、プロジェクトの ビルド.バージョン パラメーターを増分します。「リリース日の更新」とは異なり、この構成はパラメーター値を永続的に変更するための 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.<構成名>.<パラメーター名> 構文を介してアクセスできます。
「ビルドバージョンの更新」構成では REST API を使用して永続的な値を書き込むため、更新されたビルドバージョンはプロジェクトの ビルド.バージョン パラメーターから直接取得されます。

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
        }
    }
})

       

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

新しい「リリース日の更新」ビルドがトリガーされても、他の構成は影響を受けません。ビルドは、どこでも使用されない新しいパラメーター値を計算します。
「ビルドバージョンの更新」構成がトリガーされた場合、このビルドが完了すると、この構成に追加されたビルド完了トリガーにより、新しい「パッケージの更新」構成ビルドが生成されます。ただし、「パッケージの更新」には「リリース日の更新」に対するスナップショット依存関係もあるため (ビルドの再利用が無効)、現在の日付も要求されます。その結果、「ビルドバージョンの更新→ リリース日の更新→ パッケージの更新」パイプライン全体が実行されます。
新しい「パッケージの更新」ビルドがトリガーされると、まず依存関係の「リリース日の更新」ビルドが実行されます。リリースバージョンは、新しい「リリースバージョンの更新」ビルドを実行せずに、プロジェクトパラメーターから取得されます。

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

トリガーの制限

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

両方の構成に同じ VCS 設定がある場合でも、新しくトリガーされたビルドのリビジョンは、完了した追跡されたビルドと同じではない場合があります。
終了ビルドトリガーを含むビルド構成にターゲットビルド構成へのアーティファクト依存関係がある場合、監視対象ビルドのアーティファクトが使用される保証はありません。これは、トリガーされたビルドがビルドキューに残っている間に、追跡対象構成の別のビルドが終了する可能性があるために発生することがあります。
終了ビルドが別のブランチを使用している場合でも、終了ビルドトリガーによってトリガーされるビルドは、常にデフォルトのブランチでトリガーされます。
このアルゴリズムは、監視対象の構成で完了したすべてのビルドが、ビルド完了トリガーを含む構成で対応するビルドをトリガーすることを保証しません。場合によっては、たとえば監視対象の二つのビルドがほぼ同時に完了した場合、対応するビルドは一つだけトリガーされることがあります。この制限と考えられる回避策の詳細については、課題トラッカーの関連タスクを参照してください。この制限によってビルドパイプラインが何らかの形で制約を受ける場合は、ユースケースを説明するコメントをこの課題に残してください。

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

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

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

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

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

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

TeamCity では類似したタスクを複数の方法で解決でき、場合によっては別々のビルド構成を作成するほうが依然として望ましいことがあります。たとえば、同じ構成でカスタム実行が多すぎる場合、TeamCity が各ビルドの正確な所要時間を予測しにくくなることがあります。多数の異なるパラメーターでビルドをトリガーする必要がある場合は、ビルド構成テンプレートを作成し、それぞれ独自のパラメーターを持つ複数の構成のブループリントとして使用することをお勧めします。

2026 年 9 月 11 日