teamcity - ¿Opción de activación para establecer parámetros específicos de construcción?
teamcity-7.0 (5)
Agregué solicitud al último paso de compilación
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%
Estoy buscando una manera de adjuntar algún parámetro de compilación específico a un disparador programado.
La idea es que continuamente estamos construyendo versiones de depuración de nuestros productos. Sin embargo, nuestra versión nocturna tiene que ser una versión de lanzamiento. Las configuraciones de construcción para la mayoría de nuestros proyectos son absolutamente las mismas. Incluso tiene un parámetro de configuración, ya. Así que todo lo que necesitaría es un disparador que permita especificar un reemplazo para un único parámetro de compilación. Eso reduciría las configuraciones de construcción para mantener a la mitad.
¿Hay una manera de lograr esto?
El enfoque que utilizo es crear una compilación "Deploy :: Dev D1 :: Run todas las pruebas de integración". Entonces creo un desencadenador de compilación en cada compilación de servicios de integración.
Creo un parámetro llamado "env: OctopusEnvironment" para la compilación del servicio de integración. Establecer el valor para estar vacío. Me gusta usar el indicador y mostrar:
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''
En cada compilación del servicio de integración agrego este paso de 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'']"
}
}
Así que ahora puedo ejecutar la prueba de integración a través de un activador y cuando la ejecuto directamente, me indicará en qué entorno ejecutar la prueba de integración.
Esta no es una solución general, pero en ciertos casos (por ejemplo, si desea determinar si la compilación se inició mediante un desencadenante de programación o algún otro método), una solución es examinar el parámetro predefinido teamcity.build.triggeredBy .
Este parámetro se establece en la misma cadena que se muestra en la página de información general de la compilación al lado de la etiqueta "Desencadenado por:". Por ejemplo, "Schedule Trigger", "Git" o el nombre completo de un usuario. (También hay un parámetro teamcity.build.triggeredBy.username , pero solo se establece en este último caso).
La limitación de este enfoque es que no puede, por ejemplo, distinguir entre dos activadores de programación separados definidos para la misma configuración de compilación. Pero en ese caso usted podría recurrir a examinar la hora actual también.
Me quedé atrapado con el mismo problema y voté por el problema mencionado por Evgeny. Una solución que pensamos, como se mencionó en sergiussergius, fue agregar un paso final en la secuencia de pasos de compilación para activar manualmente la siguiente configuración de compilación al pasar parámetros de compilación personalizada utilizando la API REST. Pero en este caso, estamos perdiendo la información de la cadena de construcción. Al usar TeamCity 9.x, al intentar algunas cosas en la API REST, podría implementar una solución que permita recuperar la compilación desencadenante (ancestro) y sus parámetros desde la compilación desencadenada (secundaria). Lo primero que hacemos es obtener la compilación actual utilizando las variables de entorno establecidas por TeamCity:
https://<host>/httpAuth/app/rest/builds/number:<env.BUILD_NUMBER>,buildType:(name:<env.TEAMCITY_BUILDCONF_NAME>,project:<env.TEAMCITY_PROJECT_NAME>)
En la respuesta de la API REST, tenemos una etiqueta / build / triggered que contiene información sobre el disparador. Se parece a esto
<triggered type="unknown" details="##triggeredByBuildType=''<triggering-build-configuration-internalId>'' triggeredByBuild=''<triggering-build-number>''" date="20160105T190642+0700"/>
El se parece a btxxx para nosotros. Desde él, podemos acceder a la creación-desencadenante (ancestro) usando la siguiente solicitud a la API REST:
https://<host>/httpAuth/app/rest/builds/number:<triggering-build-number>''4,buildType:(internalId:<triggering-build-configuration-internalId>1,project:name:<env.TEAMCITY_PROJECT_NAME>)
a partir de la respuesta, podemos obtener los valores de los parámetros de antecesor-build y establecerlos en la compilación actual usando:
echo "##teamcity[setParameter name=''env.ENV_AAA'' value=''aaaaaaaaaa'']")
Notas:
- este post referencia TeamCity versión 7.X. Hice esto con TeamCity versión 9.X, y no pude probarlo con una versión anterior. No sé si las llamadas a la API de REST que se mencionan en mi publicación son similares en las versiones anteriores.
- En esta solución, la configuración de construcción del antepasado (la que activó la construcción) y la configuración de construcción del niño (la que se activó) están en el mismo proyecto. No hice la prueba usando configuraciones de compilación en 2 proyectos diferentes: esperaría que la etiqueta "desencadenante" proporcione información sobre el proyecto del antepasado. Sería bueno si alguien pudiera hacer la prueba.
Espero que esta solución pueda ayudar!
No ahora, puedes seguir este problema .