2012-04-04 9 views
21

Ich suche nach einer Möglichkeit, einen bestimmten Build-Parameter an einen geplanten Trigger anzuhängen.Trigger-Option zum Festlegen bestimmter Build-Parameter?

Die Idee ist, dass wir kontinuierlich Debug-Versionen unserer Produkte erstellen. Unser nächtlicher Build muss allerdings ein Release-Build sein. Die Build-Konfigurationen für die meisten unserer Projekte sind absolut identisch. Es hat sogar schon einen Konfigurationsparameter. Also brauche ich nur einen Trigger, der es ermöglicht, einen Override für einen einzelnen Build-Parameter festzulegen. Das würde die Build-Konfigurationen halbieren.

Gibt es einen Weg, dies zu erreichen?

Antwort

5

Der Ansatz, den ich verwenden ist ein "Bereitstellen :: Dev D1 :: Run alle Integrationstests" Build zu erstellen. Ich erstelle dann einen Build-Trigger für jeden Integrationsservice-Build.

Ich erstelle einen Parameter namens "env: OctopusEnvironment" für Integration Service Build. Setzen Sie den Wert auf leer. Ich mag verwenden prompt und Anzeige:

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' 

In jedem Build Integration Service, den ich diesen Power Schritt:

$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']" 
    } 
} 

So, jetzt kann ich den Integrationstest über einen Trigger laufen und wenn ich laufe es direkt Es wird mich darauf hinweisen, in welcher Umgebung der Integrationstest ausgeführt werden soll.

+4

Schöne kleine Powershell suff. Aber das kann keine Entschuldigung für JetBrains-Jungs sein, diese Funktion nicht in Teamcity selbst zu haben. –

2

Ich war mit dem gleichen Problem fest und stimmte für das von Evgeny erwähnte Thema. Eine Lösung, die wir, wie erwähnt, sergiussergius, betrachteten, bestand darin, einen letzten Schritt in der Build-Step-Sequenz hinzuzufügen, um manuell die nächste Build-Konfiguration auszulösen, indem benutzerdefinierte Build-Parameter mit der REST-API übergeben werden. In diesem Fall verlieren wir jedoch die Informationen zur Build-Chain. Mit TeamCity 9.x konnte ich einige Dinge in der REST-API ausprobieren und eine Lösung implementieren, die es ermöglicht, das auslösende (Vorgänger-) Build und seine Parameter vom ausgelösten (untergeordneten) Build abzurufen. unter Verwendung der Umgebungsvariablen werden von Teamcity Das erste, was wir tun, ist die aktuelle Build erhalten:

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

In der Antwort von dem REST-API, haben wir ein /build/ausgelöst Tag die Informationen über den Auslöser enthält . Es sieht aus wie dieses

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

Die sieht aus wie btxxx für uns. Von ihm können wir die auslösenden-build (Vorfahre) unter Verwendung der folgenden Anforderung an die REST-API zugreifen:

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

aus der Antwort können wir die Vorfahr-build-Parameter-Werte, und legen Sie es in der aktuellen bekommen Verwendung bauen:

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

Hinweise:

  • diesen Beitrag Referenzteamcity Version 7.x. Ich habe dies mit TeamCity Version 9.X gemacht und konnte es nicht mit einer früheren Version versuchen. Ich weiß nicht, ob die in meinem Beitrag genannten REST-API-Aufrufe in den vorherigen Versionen ähnlich sind.
  • In dieser Lösung befinden sich die Build-Konfiguration des Vorfahren (die den Build auslöst) und die Build-Konfiguration des Kindes (die ausgelöste) im selben Projekt. Ich habe den Test nicht mit Build-Konfigurationen in zwei verschiedenen Projekten durchgeführt: Ich würde erwarten, dass das Tag "trigger" Informationen über das Projekt des Vorfahren liefert. Es wäre schön, wenn jemand den Test machen könnte.

Ich hoffe, diese Lösung kann helfen!

Verwandte Themen