Verifique múltiples repositorios git en el mismo espacio de trabajo de Jenkins

127

Usando Jenkins 1.501 y Jenkins Git plugin 1.1.26

Tengo 3 repositorios git diferentes, cada uno con múltiples proyectos.

Ahora necesito verificar todos los proyectos de los repositorios de 3 git en el mismo espacio de trabajo en un esclavo Jenkins. He definido cada repositorio de git en: Gestión del código fuente: Múltiples SCM . Pero cada vez que se retira un repositorio, se elimina el repositorio anterior (y sus proyectos asociados).

He leído esto:

http://jenkins.361315.n4.nabble.com/multiple-git-repos-in-one-job-td4633300.html

pero en realidad no ayuda. Intenté especificar la misma carpeta en el subdirectorio Local para repositorio (opcional) para todos los repositorios, pero da el mismo resultado.

Si esto es simplemente imposible con Jenkins, supongo que se podrían usar algunos pasos / scripts previos a la compilación para mover los proyectos a la ubicación correcta. No es una opción para modificar la configuración de compilación de los proyectos.

u123
fuente

Respuestas:

69

No es posible verificar más de un repositorio a la vez en un solo espacio de trabajo con Jenkins + Git Plugin.

Como solución alternativa, puede tener múltiples trabajos ascendentes que verifican un solo repositorio cada uno y luego lo copian al espacio de trabajo del proyecto final (problemático en varios niveles), o puede configurar un paso de script de shell que verifica cada repositorio necesario para El espacio de trabajo en el momento de la construcción.

Anteriormente, el complemento Multiple SCM podría ayudar con este problema, pero ahora está en desuso. Desde la página del complemento de SCM múltiple: "Los usuarios deben migrar a https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin . Pipeline ofrece una mejor manera de verificar múltiples SCM y es compatible con Jenkins equipo de desarrollo central ".

CIGuy
fuente
¿Por qué es problemático el primer enfoque? Dividir los trabajos parece una buena práctica.
CurtainDog
1
Es una buena práctica en general, pero cuando necesita múltiples pagos en la misma ubicación física, el mantenimiento se convierte en una gran preocupación. Por ejemplo, si desea crear una compilación de rama, tendría que clonar 4 trabajos y luego cambiar individualmente las rutas para cada uno. Por supuesto, hay complementos para ayudar con esto, pero es más fácil simplemente pagar a una ruta relativa desde un solo trabajo. Luego puede clonar tanto como desee sin cambiar la configuración.
CIGuy
1
Necesitas cambiarlo de la respuesta correcta ya que ya no es relevante.
Dvir669
2
Las canalizaciones requieren que aprenda un nuevo DSL, que es demasiado para el simple trabajo (consulte el código de múltiples repositorios) que queremos que haga. Apéguese al complemento SCM múltiple hasta que aparezca una GUI decente alrededor del DSL de canalización de Jenkins. Puedo informar que ha estado funcionando bien con Jenkins 2.17
Burak Arslan
2
Acabo de encontrar los mismos problemas con múltiples repositorios. Ahora estoy usando el complemento Pipeline a pesar de que era tan escéptico como @BurakArslan sobre el nuevo DSL. En realidad, no es tan malo como pensaba y viene con un generador de fragmentos razonablemente decente. Después de usarlo durante solo 2 horas, ahora prefiero este enfoque, ya que eventualmente puedo confirmar los scripts de compilación de la tubería para unirlos con el resto del código.
Ben
81

Con el complemento SCM múltiple:

  • cree una entrada de repositorio diferente para cada repositorio que necesite pagar (proyecto principal o proyecto de dependencia).

  • para cada proyecto, en el menú "avanzado" (el segundo menú "avanzado", hay dos botones etiquetados como "avanzado" para cada repositorio), busque el campo de texto "Subdirectorio local para repositorio (opcional)". Puede especificar allí el subdirectorio en el directorio "espacio de trabajo" donde desea copiar el proyecto. Podrías mapear el sistema de archivos de mi computadora de desarrollo.

El "segundo menú avanzado" ya no existe, en su lugar, lo que hay que hacer es usar el botón "Agregar" (en la sección "Comportamientos adicionales") y elegir "Verificar en un subdirectorio"

  • si está utilizando ant, como ahora el archivo build.xml con los objetivos de compilación no en el directorio raíz del espacio de trabajo sino en un subdirectorio, debe reflejar eso en la configuración "Invocar Ant". Para hacerlo, en "Invocar hormiga", presione "Avanzado" y complete el texto de entrada "Crear archivo", incluido el nombre del subdirectorio donde se encuentra el build.xml.

Espero que ayude.

GaRRaPeTa
fuente
3
Esto debe estar desactualizado. Al momento de escribir, el fragmento GIT del complemento Múltiples SCM no contiene la subruta opcional.
AlexeiOst
12
En cada repositorio hay una lista desplegable llamada "Agregar". En él puede encontrar la opción "Pagar a un subdirectorio", que realiza lo mismo.
Gary Ye
1
Seguí tu guía con el complemento SCM múltiple y git pero tengo otro problema divertido. Parece que no desea verificar adecuadamente la misma rama (desarrollar) para diferentes repositorios. Intenta pagar un commit por hash (que es válido solo en el primer repositorio). ¿Alguna idea sobre cómo abordar esto?
Lefteris
El mayor problema con el complemento SCM múltiple es el siguiente: "Los activadores de tipo post-commit no funcionan actualmente (al menos para la subversión), por lo que es necesario configurar el sondeo de tipo 'cron'".
grayaii
1
Las canalizaciones requieren que aprenda un nuevo DSL, que es demasiado para el simple trabajo (consulte el código de múltiples repositorios) que queremos que haga. Apéguese al complemento SCM múltiple hasta que aparezca una GUI decente alrededor del DSL de canalización de Jenkins. Puedo informar que ha estado funcionando bien con Jenkins 2.17
Burak Arslan
41

Dado que el complemento SCM múltiple está en desuso.

Con Jenkins Pipeline es posible verificar múltiples repositorios git y después de construirlo usando gradle

node {   
def gradleHome

stage('Prepare/Checkout') { // for display purposes
    git branch: 'develop', url: 'https://github.com/WtfJoke/Any.git'

    dir('a-child-repo') {
       git branch: 'develop', url: 'https://github.com/WtfJoke/AnyChild.git'
    }

    env.JAVA_HOME="${tool 'JDK8'}"
    env.PATH="${env.JAVA_HOME}/bin:${env.PATH}" // set java home in jdk environment
    gradleHome = tool '3.4.1' 
}

stage('Build') {
  // Run the gradle build
  if (isUnix()) {
     sh "'${gradleHome}/bin/gradle' clean build"
  } else {
     bat(/"${gradleHome}\bin\gradle" clean build/)
  }
}
}

Es posible que desee considerar el uso de submódulos git en lugar de una tubería personalizada como esta.

bufón
fuente
¡¡¡Gracias!!! El dirbloque es clave, no pude entender por qué solo estaba viendo el repositorio clonado más recientemente en el espacio de trabajo de mi trabajo.
bonh
¿Cómo se considera la noción de "cambios" en múltiples SCM? ¿Es solo la suma de los cambios vistos de todos los repositorios que componen los trabajos? Sería bueno detallarlos de cada uno si es posible, 23 changes from repo XXX, 3 changes from repo YYYo algo más compacto en ese sentido.
jxramos
20

Utilicé el complemento Múltiples SCM junto con el complemento Git con éxito con Jenkins.

Frederik Deweerdt
fuente
3
gracias, eso es genial, soy capaz de poner 2 rutas de bitbucket en la sección del repositorio, y ahora ¿cómo puedo decirle a la rama "desarrollar" el pago del repo 1 y para la rama "arreglos" del pago del repo 2? Veo las ramas para construir la porción en jenkins, ¿cómo puedo configurar el nombre del repositorio y Refsec en el especificador de la rama (en blanco para 'cualquiera') para que cada uno pueda ver la rama correspondiente que quiero? o lo estoy haciendo de frente y debería hacer clic en el booleano que dice "Múltiples SCM"?
pelos
@pelos ¿Pudiste encontrar la solución?
Govind
en este momento no usamos el archivo yml e hicimos los dos flujos de trabajo diferentes con las tareas habituales
pelos
5

Dependiendo de las relaciones de los repositorios, otro enfoque es agregar el otro repositorio (repositorios) como submódulos git a uno de los repositorios. Un submódulo git crea una referencia a los otros repositorios. Esos repositorios de submódulos no se clonan a menos que especifique la --recursivebandera al clonar el "superproyecto" (término oficial).

Aquí está el comando para agregar un submódulo al proyecto actual:

git submodule add <repository URI path to clone>

Estamos utilizando Jenkins v1.645 y el git SCM listo para usar hará un clon recursivo para superproyectos. De este modo, obtiene los archivos de superproyectos y todos los archivos de repositorios dependientes (submódulo) en sus propios directorios respectivos en el mismo espacio de trabajo de Jenkins.

No garantizo que este es el enfoque correcto , sino que es un enfoque.

mikehwang
fuente
5

Jenkins: Múltiple SCM - en desuso. Complemento GIT: no funciona para múltiples repositorios.

Scripting / pipeline as code - es el camino a seguir.

AKS
fuente
2

Yo también tuve este problema. Lo resolví usando Trigger / call builds en otros proyectos. Para cada repositorio, llamo al proyecto descendente utilizando parámetros.

Proyecto principal:

This project is parameterized
String Parameters: PREFIX, MARKETNAME, BRANCH, TAG
Use Custom workspace: ${PREFIX}/${MARKETNAME}
Source code management: None

Luego, para cada repositorio, llamo a un proyecto posterior como este:

Trigger/call builds on other projects: 
Projects to build: Linux-Tag-Checkout
Current Build Parameters
Predefined Parameters: REPOSITORY=<name>

Proyecto aguas abajo: Linux-Tag-Checkout:

This project is parameterized
String Parameters: PREFIX, MARKETNAME, REPOSITORY, BRANCH, TAG
Use Custom workspace:${PREFIX}/${MARKETNAME}/${REPOSITORY}-${BRANCH}
Source code management: Git
git@<host>:${REPOSITORY}
refspec: +refs/tags/${TAG}:refs/remotes/origin/tags/${TAG}
Branch Specifier: */tags/${TAG} 
Torbjörn Gard
fuente
1

El registro de salida más de una cesión temporal a la vez en un único espacio de trabajo es posible con Jenkins + Git Plugin (tal vez sólo en las versiones más recientes?).

En la sección "Gestión del código fuente", no seleccione "Git", sino "Múltiples SCM" y agregue varios repositorios git.

Asegúrese de que en todos menos uno agregue como "Comportamiento adicional" la acción "Verificar en un subdirectorio" y especifique un subdirectorio individual.

JRA_TLL
fuente
Creo que de esta manera está utilizando el complemento SCM múltiple (en desuso) en lugar del complemento Git de vainilla.
Robert
0

Estamos usando git-repo para administrar nuestros múltiples repositorios GIT. También hay un complemento Jenkins Repo que permite retirar todos o parte de los repositorios administrados por git-repo en el mismo espacio de trabajo de Jenkins.

vladisld
fuente
¿Cómo resuelve exactamente el problema planteado en esta pregunta? He instalado el plugin usted ha mencionado, y leer acerca de recompra y el plugin, pero no puedo ver cómo configurar Jenkins al clon de dos repositorios para ejecutar en un proyecto ...
GreenAsJade
Para utilizar Repo, se debe crear el repositorio especial que contendrá solo los archivos de manifiesto. En este archivo, especifica toda la información sobre otros repositorios. El formato exacto de los archivos de manifiesto se describe en el archivo docs / manifest-format.txt del proyecto git-repo ( gerrit.googlesource.com/git-repo/+/master/docs/… ). Al configurar Jenkins Repo parte del trabajo: debe especificar la ubicación del repositorio 'manifiesto' y, opcionalmente, el nombre de los archivos 'manifiesto' (puede tener varios). Todos los repositorios especificados en el manifiesto serán clonados.
vladisld