tutorial steps first example español jenkins jenkins-workflow jenkins-2 jenkinsfile

steps - Jenkins: Activación de tuberías de múltiples sucursales en el cambio hacia el origen



jenkins pipeline tutorial español (3)

Actualmente estoy tratando de hacer que esto funcione para nuestra implementación. Lo más cercano que tengo es agregar lo siguiente al archivo Jenkins descendente;

properties([ pipelineTriggers([ triggers: [ [ $class: ''jenkins.triggers.ReverseBuildTrigger'', upstreamProjects: "some_project", threshold: hudson.model.Result.SUCCESS ] ] ]), ])

Eso, al menos, hace que Jenkins reconozca que debería activarse cuando se construya ''some_project'', es decir, aparece en la página "Ver configuración".

Sin embargo, hasta ahora las compilaciones de ''some_project'' todavía no activan el proyecto posterior como se esperaba.

Dicho esto, tal vez tengas más suerte. Déjame saber si te funciona.

(Alguien más ha formulado una pregunta similar sobre la canalización de múltiples sucursales de Jenkins y la especificación de proyectos ascendentes )

Actualmente estoy probando el enfoque de canalización de Jenkins 2.0 para ver si funciona para el entorno de compilación que estoy usando.

Primero sobre el medio ambiente en sí. Actualmente consta de múltiples repositorios SCM. Cada repositorio contiene varias ramas, para las diferentes etapas del desarrollo y cada rama se construye con múltiples configuraciones. No todas las configuraciones se aplican a todos los repositorios.

Actualmente, cada repositorio / sucursal se configura como un proyecto de matriz para las diferentes configuraciones. Cada proyecto expone sus resultados de construcción como un artefacto y estos artefactos se utilizan en los proyectos posteriores.

Los diferentes repositorios dependen unos de otros, por lo que una compilación exitosa en un trabajo ascendente desencadena algunos trabajos de flujo descendente específicos. Actualmente, todo eso funciona, pero la cantidad de trabajo requerido para configurar una nueva sucursal o para modificar el proceso de construcción es mucho, ya que muchos proyectos diferentes deben modificarse a mano.

Ahora quería probar las nuevas tuberías. Mi idea fue crear proyectos de canalización de múltiples sucursales y colocar un Jenkinsfile dentro del repositorio que contiene las instrucciones para la compilación.

El principal problema es hacer que las compilaciones se activen unas a otras, porque básicamente una compilación en una rama ascendente específica, debe desencadenar una rama descendente. Sin embargo, el proyecto de flujo ascendente no conoce la información de qué ramas deben ser activadas. Cada proyecto en sentido descendente obtiene los artefactos de algunas ramas en sentido ascendente y la solución ideal sería si la compilación en sentido descendente se activaría en caso de que la compilación en sentido ascendente que es la fuente de los artefactos termine su compilación.

El problema es que solo los proyectos posteriores realmente saben qué artefactos requieren. Es poco probable que los nombres de las sucursales coincidan en la mayoría de los casos y eso hace que sea muy difícil desencadenar las compilaciones desde el proyecto ascendente.

Actualmente esto se resuelve utilizando el ReverseBuildTrigger . Pero esto deja de funcionar tan pronto como se acerca a una tubería.

Estoy realmente en una pérdida cómo hacer que esto funcione. ¿Hay alguna manera de hacer que algo como el ReverseBuildTrigger funcione dentro de los scripts de tuberías?

Además, no es una opción activar la compilación descendente completa para todas las ramas en caso de que se cambie una sola rama en sentido ascendente. Esto crearía demasiadas construcciones iguales.


Si está utilizando una canalización declarativa de múltiples sucursales , puede usar:

triggers { upstream(upstreamProjects: "some_project/some_branch", threshold: hudson.model.Result.SUCCESS) }

Si desea que se produzcan coincidencias de rama en las dependencias, puede utilizar:

triggers { upstream(upstreamProjects: "some_project/" + env.BRANCH_NAME.replaceAll("/", "%2F"), threshold: hudson.model.Result.SUCCESS) }


La configuración de Pipeline Job aún admite de forma nativa los desencadenadores de compilación , incluido el desencadenante de compilación inversa, compilación después de que se hayan construido otros proyectos . Incluso puede especificar una sucursal del proyecto Pipeline Multi-branch .

Desafortunadamente, la activación inversa no está disponible Pipeline Trabajos de sucursales múltiples . Lo más cerca que puede llegar a la activación inversa es mediante el uso del complemento de compilaciones promocionadas . Pero todavía no te deja configurar por ramificación de configuración.

Además, Snippet Generator aclara:

Las siguientes variables no están disponibles actualmente dentro de un script de Pipeline:

NODE_LABELS WORKSPACE SCM variables específicas, como SVN_REVISION

PD. Tal vez la única forma sería incitar de arriba a abajo .