Jenkins: ¿pasar variables entre trabajos?

Tengo dos trabajos en jenkins, y ambos necesitan el mismo parámetro.

¿Cómo puedo ejecutar el primer trabajo con un parámetro para que cuando active el segundo trabajo, se use el mismo parámetro?

Puede utilizar el complemento de disparador parametrizado que le permitirá pasar parámetros de una tarea a otra.

También necesita agregar este parámetro que pasó de aguas arriba en aguas abajo.

1. Acciones posteriores a la compilación> Seleccione "Activar compilación parametrizada en otros proyectos"

Ingrese la variable de entorno con valor. El valor también puede ser Parámetros de compilación de Jenkins.

Los pasos detallados se pueden ver aquí: -

https://itisatechiesworld.wordpress.com/jenkins-related-articles/jenkins-configuration/jenkins-passing-a-parameter-from-one-job-to-another/

Espero que sea útil :)

La respuesta aceptada aquí no funciona para mi caso de uso. Necesitaba poder crear parámetros dinámicamente en un trabajo y pasarlos a otro. Como menciona Mark McKenna, aparentemente no hay forma de exportar una variable desde un paso de compilación de shell a las acciones posteriores a la compilación.

Logré una solución alternativa usando el Complemento de disparador parametrizado escribiendo los valores en un archivo y usando ese archivo como los parámetros para importar a través de 'Agregar acción posterior a la compilación' -> 'Compilación parametrizada de gatillo ...' y luego seleccionando 'Agregar parámetros' - > 'Parámetros del archivo de propiedades'.

Creo que la respuesta anterior necesita una actualización:

Estaba tratando de crear un directorio dinámico para almacenar mis artefactos de compilación ascendentes, así que quería pasar el número de compilación de mi trabajo ascendente al trabajo descendente. Intenté los pasos anteriores pero no pude hacerlo funcionar. Así es como funcionó:

1. Copié los artefactos de mi trabajo actual usando el complemento de copiar artefactos.
2. En la acción posterior a la construcción del trabajo aguas arriba, agregué la variable como "SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}" y la configuré para activar el trabajo aguas abajo.
3. Todo funcionó, excepto que mi trabajo posterior no pudo obtener $ SOURCE_BUILD_NUMBER para crear el directorio.
4. Entonces descubrí que para usar esta variable tengo que definir la misma variable en el trabajo de flujo descendente como una variable de parámetro como en esta imagen a continuación:

Esto se debe a que la nueva versión de jenkins también requiere que defina la variable en el trabajo posterior. Espero que sea de ayuda.

(para compañeros de Google)

Si está construyendo una canalización seria con Build Flow Plugin , puede pasar parámetros entre trabajos con el DSL de la siguiente manera:

Suponiendo un parámetro de cadena disponible "CVS_TAG", para pasarlo a otros trabajos:

build("pipeline_begin", CVS_TAG: params['CVS_TAG'])
parallel (
   // will be scheduled in parallel.
   { build("pipeline_static_analysis", CVS_TAG: params['CVS_TAG']) },
   { build("pipeline_nonreg", CVS_TAG: params['CVS_TAG']) }
)
// will be triggered after previous jobs complete
build("pipeline_end", CVS_TAG: params['CVS_TAG'])

Sugerencia para mostrar variables / parámetros disponibles:

// output values
out.println '------------------------------------'
out.println 'Triggered Parameters Map:'
out.println params
out.println '------------------------------------'
out.println 'Build Object Properties:'
build.properties.each { out.println "$it.key -> $it.value" }
out.println '------------------------------------'

Solo agregue mi respuesta además de la de Nigel Kirby, ya que aún no puedo comentar:

Para pasar un parámetro creado dinámicamente, también puede exportar la variable en el mosaico 'Ejecutar Shell' y luego pasarla a través de 'Desencadenar compilación parametrizada en otros proyectos' => 'Parámetros predefinidos "=> dar' YOUR_VAR = $ YOUR_VAR '. Mi equipo usa esta función para pasar la versión del paquete npm del trabajo de compilación a los trabajos de implementación

ACTUALIZACIÓN: lo anterior solo funciona para los parámetros inyectados de Jenkins, el parámetro creado desde el shell aún necesita usar el mismo método. p.ej. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties y pase ese archivo en sentido descendente

Enfrenté el mismo problema cuando tuve que pasar una versión pom a un trabajo posterior de Rundeck.

Lo que hice fue usar la inyección de parámetros a través de un archivo de propiedades como tal:

1) Crear propiedades en el archivo de propiedades a través de shell:

Construir acciones:

• Ejecutar un script de shell
• Inyectar variables de entorno

P.ej : definición de propiedades

2) Pasar propiedades definidas al trabajo posterior: Acciones posteriores a la construcción:

• Activar compilación parametrizada en otro proyecto
• Agregar parámetros: parámetros de compilación actuales
• Agregar parámetros: parámetros predefinidos

P.ej : envío de propiedades

3) Entonces fue posible usar $ POM_VERSION como tal en el trabajo Rundeck posterior.

/! \ Jenkins Versión: 1.636

/! \ Por alguna razón, al crear la compilación activada, fue necesario agregar la opción 'Parámetros de compilación actuales' para pasar las propiedades.

Al leer las respuestas, no veo otra opción que me guste, así que la ofreceré también. Me encanta la parametrización de trabajos, pero no siempre se adapta bien. Si tiene trabajos que no están directamente aguas abajo del primer trabajo sino más adelante en la canalización, realmente no desea parametrizar cada trabajo en la canalización para poder pasar los parámetros hasta el final. O si tiene una gran cantidad de parámetros utilizados por una variedad de otros trabajos (especialmente aquellos que no están necesariamente vinculados a un trabajo principal o maestro), nuevamente la parametrización no funciona.

En estos casos, prefiero enviar los valores a un archivo de propiedades y luego inyectarlos en cualquier trabajo que necesite usando el complemento EnvInject . Esto se puede hacer dinámicamente, que es otra forma de resolver el problema de otra respuesta anterior donde todavía se usaban trabajos parametrizados. Esta solución se adapta muy bien a muchos escenarios.

Puede usar el constructor Hudson Groovy para hacer esto.

Primer trabajo en proceso

Segundo trabajo en cartera

¡Me lo imaginé!

Con casi 2 horas de prueba y error, lo descubrí.

Esto FUNCIONA y es lo que debe hacer para pasar variables al trabajo remoto:

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2=${env.param2}")

Utilice \ n para separar dos parámetros, sin espacios.

A diferencia de los parámetros: '' 'someparams' ''

usamos paramters: "someparams"

el "..." es lo que nos da los valores de las variables deseadas. (Estas son comillas dobles, no dos comillas simples)

los '' '...' '' o '...' no nos darán esos valores. (Tres comillas simples o solo comillas simples)

Todos los parámetros aquí se definen en el bloque de entorno {} al inicio de la canalización y se modifican en etapas> pasos> scripts donde sea necesario.

También probé y descubrí que cuando usas "..." no puedes usar algo como '' '... "..."' '' o "... '..'..." o cualquier combinación de eso...

El problema aquí es que cuando usa "..." en la sección de parámetros, no puede pasar un parámetro de cadena; por ejemplo, esto NO FUNCIONARÁ:

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2='param2'")

si desea pasar algo como el anterior, deberá establecer una variable de entorno param2 = 'param2' y luego usar $ {env.param2} en la sección de parámetros del paso del complemento de activación remota