continuous integration - ¿Cómo puedo anular el nombre de rama<default> en TeamCity 7.1 utilizando el soporte de bifurcación de Git?

continuous-integration git-branch

Question

Tengo una compilación CI que extrae las sucursales de Github y las construyo / empaqueté en una carpeta local, utilizando una convención de nombres de carpetas basada en el proyecto, la sucursal y el número de compilación.

Para las ramas con nombre (feature1, feature2) esto está funcionando muy bien.

El problema es que cuando hago un compromiso con el maestro, TeamCity expone teamcity.build.branch como <default> , lo que significa que cuando el paso de compilación se expande

E:/Packages/MyProject/%teamcity.build.branch%/

termina con E:/Packages/MyProject/<default> , que luego bloquea el paso de compilación porque no es una ruta de Windows válida.

Puedo ver el nombre de la rama maestra en el parámetro de compilación completamente calificado:

teamcity.build.branch                         <default>
teamcity.build.checkoutDir                    C:/TeamCity/BuildAgents/agent-mulder/work/2151838a7933464d
teamcity.build.default.checkoutDir            2151838a7933464d
teamcity.build.id                             16347
teamcity.build.vcs.branch.github_myproject    refs/heads/master

pero idealmente necesito obtener master como teamcity.build.branch para usar en mis pasos de compilación.

¿Puedo transformar el parámetro en tiempo de ejecución? ¿Anular el comportamiento? Incluso he intentado establecer el nombre de la rama VCS en DO_NOT_USE con la esperanza de que "master" ya no coincida con el valor predeterminado, pero esto tampoco parece funcionar.

Answer 1

En teamcity 7 simplemente se desarrolla% vcsroot.branch% que devuelve.

En mi caso tengo

%MajorVersion%.%MinorVersion%.%PatchVersion%-%vcsroot.branch%

Que están todos configurados en los parámetros de construcción. El formato del número es% BuildFormatSemVer%, que es lo que está arriba y. {0}

%BuildFormatSemVer%.{0}

Que devuelve

#1.0.0-develop.4

Answer 2

No es lo ideal, pero pude evitarlo creando una nueva sucursal en git llamada "teamcity" y estableciendo que como la rama predeterminada en TeamCity, parece que la sucursal realmente existe, ya que funcionó cuando creé la sucursal. , pero no cuando acabas de ingresar un nombre falso.

Esperemos que realmente solucionen esto, porque esto es definitivamente un hack.

Answer 3

No sé si esto fue respondido previamente, o si ya es relevante.

En TeamCity 10.0.2, cree un parámetro personalizado como% Git.Reference%. Si necesita un tirón (o empuje) de TC a git, configure esto en "ref / head / Dev" o "ref / Head / yourbranch". Use esto en su referencia ''VCS root''.

Answer 4

Nos hemos encontrado con este problema varias veces al crear tuberías. Es lo más visible cuando se trata de crear automáticamente características y liberar sucursales utilizando el flujo de trabajo de Gitflow. Lo que hemos podido hacer fue utilizar teamcity.build.vcs.branch.github_myproject y una expresión regular en sed para desinfectar la cadena cada vez que deseamos usarla. Esto se debe principalmente a los artefactos de marca de agua para fines de depuración.

El problema mayor, al menos para nosotros, es que la versión de TeamCity 7.1.1 no dispara automáticamente las compilaciones de dependencia para cualquier cosa que no sea la compilación predeterminada en la raíz VCS. Obviamente, este es un punto de gran dolor, ya que ahora tendremos que hacer clic manualmente en la herramienta. Todavía no hemos descubierto una manera limpia de evitar esto, aparte de los enganches en git que usan la API HTTP para llamar al paso de compilación adecuado.