installations - La rama activa de Git es "(sin rama)" en hudson CI

jenkins pipeline git

Question

Mi secuencia de comandos build.xml de Ant comienza con

<property environment="env"/>
<echo>GIT_BRANCH = ${env.GIT_BRANCH}</echo>
<echo>PWD = ${env.PWD}</echo>

Hudson CI está configurado para construir cuando cambia cualquier rama. La salida de la consola es ...

Commencing build of Revision 90906a63929e9074035eb5b10c71ee055ad3e13c (origin/DPM-48)
GitAPI created
Checking out Revision 90906a63929e9074035eb5b10c71ee055ad3e13c (origin/DPM-48)
[workspace] $ git.exe checkout -f 90906a63929e9074035eb5b10c71ee055ad3e13c
[workspace] $ cmd.exe /C ''"C:/Program Files/WinAnt/bin/ant.bat" -file build.xml ...''
[echo] GIT_BRANCH = ${env.GIT_BRANCH}
[echo] PWD = /cygdrive/d/.hudson

Desde la salida de la consola, Hudson sabe que está construyendo la rama temática DPM-48, pero la variable de entorno GIT_BRANCH no está establecida y la ''rama git'' devuelve que git está en un estado ''HEAD separado''

* (no branch)
master
DPM-48

Lo que quiero saber es qué rama estoy construyendo en Hudson. Tiene que haber una manera de hacer esto.

Answer 1

¡Muchas gracias por compartir esta solución!

Tuve algunos problemas para encontrar este cuadro de diálogo opcional para establecer la sucursal local, y para mostrar a otros que este también es el enfoque actual también en el año 2015 Me gustaría adjuntar algunas capturas de pantalla de los diálogos de gui actuales de Jenkins.

Answer 2

Nota: el comentario del refiere al reciente issues.hudson-ci.org/browse/HUDSON-6856 (junio de 2010), que menciona:

Git construye con la cabeza separada no importa qué

Si bien no está claro si ese problema en particular se resolverá (¡las respuestas sugieren que en realidad podría "funcionar como se diseñó"!), También se refiere a esta versión de hudson Git Plugin , que permite verificar una sucursal local.

Usted está en una DETACHED HEAD porque, como el complemento git está funcionando en este momento, realizó la verificación directamente de un SHA1 de confirmación, y no de una HEAD sucursal.

El estado en el que se encuentra mientras se desconecta su HEAD no está registrado por ninguna rama (lo cual es natural, usted no está en ninguna rama). Lo que esto significa es que puedes descartar tus compromisos y combinaciones temporales al volver a cambiar a una rama existente.

Su script de construcción podría primero intentar encontrar de qué rama proviene el compromiso relevante .

Como el OP dio cuenta al mirar el github.com/hudson/Hudson-GIT-plugin/blob/master/src/main/java/… :

public void buildEnvVars(AbstractBuild build, java.util.Map<String, String> env) {
super.buildEnvVars(build, env);
String branch = getSingleBranch(build);
if(branch != null){
env.put(GIT_BRANCH, branch);
}
}

Se establece una variable de entorno GIT_BRANCH , pero no parece tener ningún valor en el script de compilación xml:

<property environment="env"/>
<echo>GIT_BRANCH = ${env.GIT_BRANCH}</echo>

Si ese es el caso, puede ser debido al problema 7554 :

GIT_BRANCH no se establece cuando se seleccionan varias ramas para la compilación

Al tratar de identificar en qué rama están las compilaciones actuales, descubrí que la variable de entorno GIT_BRANCH no se establece cuando se selecciona más de una rama para GIT_BRANCH .

Creo que esto no es realmente un error sino una solicitud de función: la GIT_BRANCH env solo se establece si hay una sola rama, por lo que no es relevante si hay varias sucursales. No estoy seguro de cómo dar formato a una variable env para múltiples sucursales en este contexto.

Pensé que GIT_BRANCH se establecerá en la rama que se está construyendo actualmente. Al igual que si la construcción está en el maestro, contendrá el maestro.

Eso ayudaría, por ejemplo, a empujar a otro remoto que se construyó durante esta compilación. O Activar otra compilación con el conjunto de bifurcaciones correcto a construir.

Tipo de espejo que describe la NPE aquí.

Por alguna razón, el complemento de Git comenzó a pasar un valor nulo para la variable de entorno GIT_BRANCH .
Esto hizo que el complemento de Maven fallara en la System.getProperties().putAll(systemProps) .

La solución fue usar " master " como rama Git predeterminada en lugar de " ** " o String vacío.

Answer 3

RESUELTO

Después de ver el comentario de Abayer en issues.hudson-ci.org/browse/HUDSON-6856 , seguí los siguientes pasos:

• Usando el Administrador de complementos de Hudson, actualicé mi versión 1.1 de Hudson Git Plugin para obtener la corrección de Abayer.
• Usando la configuración de trabajo de Hudson, hice clic en el botón "Avanzado" debajo de "Administración del código fuente" -> "Ramas para construir". Entonces cambié la "rama local para usar" a algo para usar para un nombre. No importa qué.
• Luego hice clic en el botón "Guardar" e inicié una compilación con "Crear ahora"

El registro de compilación muestra

[workspace] $ git.exe checkout -b ChangeTester d6caef27759495c5714923c1ddf19551a70d6083

En lugar de

[workspace] $ git.exe checkout -f d6caef27759495c5714923c1ddf19551a70d6083

Lo que significa que no estoy en un estado de "cabeza separada" y, por lo tanto, puedo hacer confirmaciones, crear etiquetas y empujar.

Puedo usar ''git rev-parse HEAD'' para obtener el hash de confirmación y encontrarlo en la salida de ''git show-ref'' para encontrar el nombre real de la rama si lo necesito.

Ahora puedo insertar etiquetas de compilación exitosas en mi repositorio git.