web-dev-qa-db-ja.com

特定のビルドパラメータを設定するためのトリガーオプション？

スケジュールされたトリガーに特定のビルドパラメーターをアタッチする方法を探しています。

アイデアは、製品のデバッグバージョンを継続的に構築しているということです。ただし、ナイトリービルドはリリースビルドである必要があります。ほとんどのプロジェクトのビルド構成はまったく同じです。すでに構成パラメーターもあります。したがって、必要なのは、単一のビルドパラメーターのオーバーライドを指定できるトリガーだけです。これにより、ビルド構成が半分に削減されます。

これを達成する方法はありますか？

teamcityteamcity-7.0
27
freefall

今ではありません、あなたはフォローすることができます この問題 。

9
Evgeny Goldin

私が使用するアプローチは、「Deploy :: Dev D1 ::すべての統合テストを実行する」ビルドを作成することです。次に、統合サービスのビルドごとにビルドトリガーを作成します。

統合サービスビルド用に「env：OctopusEnvironment」というパラメーターを作成します。値を空に設定します。プロンプトと表示を使用するのが好きです：

select display='Prompt' label='OctopusEnvironment' data_13='Production' data_12='CI' data_11='Local - Hassan' data_10='Local - Mustafa' description='OctopusEnvironment' data_02='Test T1' data_01='Dev D1' data_04='Local - Taliesin' data_03='Continuous Deployment CI 1' data_06='Local - Paulius' data_05='Local - Ravi' data_08='Local - Venkata' data_07='Local - Marko' data_09='Local - Ivan'

各統合サービスのビルドで、次のPowerShellステップを追加します。

$octopusEnvironment = ($env:OctopusEnvironment).Trim()

Write-Host "Octopus environment = '$octopusEnvironment'"
if ($octopusEnvironment.Length -lt 1) {
    Write-Host "Auto detecting octopus environment"
    $trigger = '%teamcity.build.triggeredBy%' -split '::'
    if ($trigger.Length -gt 2){
        $environment = $trigger[1].Trim()
        Write-Host "##teamcity[setParameter name='env.OctopusEnvironment' value='$environment']"
    }
}

これで、トリガーを介して統合テストを実行できます。直接実行すると、統合テストを実行する環境を尋ねられます。

6
Taliesin

私は同じ問題で立ち往生し、Evgenyが言及した問題に投票しました。 sergiussergiusで述べたように、私たちが考えた1つの解決策は、ビルドステップシーケンスに最後のステップを追加して、REST APIを使用してカスタムビルドパラメーターを渡すことにより、次のビルド構成を手動でトリガーすることでした。この場合、ビルドチェーン情報が失われています。TeamCity9.xを使用して、REST APIでいくつかのことを試して、トリガーを取得できるようにするソリューションを実装できます（祖先）ビルドとトリガーされた（子）ビルドからのそのパラメーター最初に行うことは、TeamCityによって設定された環境変数を使用して現在のビルドを取得することです。

https://<Host>/httpAuth/app/rest/builds/number:<env.BUILD_NUMBER>,buildType:(name:<env.TEAMCITY_BUILDCONF_NAME>,project:<env.TEAMCITY_PROJECT_NAME>)

REST APIからの応答には、トリガーに関する情報を含む/ build/triggeredタグがあります。次のようになります。

<triggered type="unknown" details="##triggeredByBuildType='<triggering-build-configuration-internalId>' triggeredByBuild='<triggering-build-number>'" date="20160105T190642+0700"/>

私たちにとってはbtxxxのように見えます。そこから、REST APIへの次のリクエストを使用してtriggering-build（祖先）にアクセスできます。

https://<Host>/httpAuth/app/rest/builds/number:<triggering-build-number>'4,buildType:(internalId:<triggering-build-configuration-internalId>1,project:name:<env.TEAMCITY_PROJECT_NAME>)

応答から、ancestor-buildのパラメーター値を取得し、以下を使用して現在のビルドに設定できます。

echo "##teamcity[setParameter name='env.ENV_AAA' value='aaaaaaaaaa']")

ノート：

  • この投稿はTeamCityバージョン7.Xを参照しています。 TeamCityバージョン9.Xを使用してこれを行いましたが、以前のバージョンでは試すことができませんでした。私の投稿で言及されているREST API呼び出しが、以前のバージョンと類似しているかどうかはわかりません。
  • このソリューションでは、祖先のビルド構成（ビルドをトリガーするもの）と子のビルド構成（トリガーされるもの）が同じプロジェクトにあります。 2つの異なるプロジェクトでビルド構成を使用してテストを実行しませんでした。「trigger」タグが祖先のプロジェクトに関する情報を提供することを期待します。誰かがテストをしてくれたらいいのにと思います。

この解決策が役立つことを願っています！

2
Francois Gergaud

これは一般的な解決策ではありませんが、特定の場合（たとえば、ビルドがスケジュールトリガーまたはその他の方法で開始されたかどうかを確認する場合）、回避策は事前定義されたパラメーターteamcity.build.triggeredByを調べることです。

このパラメーターは、ビルドの概要ページの「トリガー元：」というラベルの横に表示されるのと同じ文字列に設定されます。たとえば、「Schedule Trigger」、「Git」、またはユーザーのフルネーム。 （teamcity.build.triggeredBy.usernameパラメーターもありますが、後者の場合にのみ設定されます）。

このアプローチの制限は、たとえば、同じビルド構成に対して定義された2つの別々のスケジュールトリガーを区別できないことです。ただし、その場合は、現在の時刻を調べることもできます。

1
Todd Owen

最後のビルドステップにリクエストを追加しました

curl -i -u "%login%:%pass%" -H "Content-type: text/plain" -X PUT -d "v1" http://tc.server/httpAuth/app/rest/buildTypes/id:%buildConfigurationId%/parameters/env.%SOME_PARAMETER%

http://confluence.jetbrains.com/display/TCD8/REST+API

1
sergiussergius