Jenkins-pasando variables entre trabajos?

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

2.Introduzca la variable de entorno con valor.El valor también puede ser Jenkins Build Parameters.

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 ser capaz de crear parámetros dinámicamente en un trabajo y pasarlos a otro. Como Mark McKenna menciona, aparentemente no hay manera de exportar una variable desde un paso de compilación del shell a las acciones de compilación post.

Logré una solución utilizando 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 'Add post-build action' - > 'Activar compilación parametrizada...'a continuación, seleccione' Añadir parámetros '- > 'Parámetros del archivo de propiedades'.

(para compañeros de Google)

Si está construyendo una canalización seria con el complemento Build Flow , 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 '------------------------------------'

Creo que la respuesta anterior necesita alguna actualización:

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

1. Copié los artefactos de mi trabajo actual usando el complemento copiar artefactos.
2. En la acción post build del trabajo upstream agregué la variable como "SOURCE_BUILD_NUMBER={{BUILD_NUMBER}" y configuré para activar el trabajo aguas abajo.
3. Todo funcionó excepto que mi trabajo de downstream no fue capaz de obtener S SOURCE_BUILD_NUMBER para crear el directorio.
4. Así que descubrí que para usar esta variable tengo que definir la misma variable en down stream job como una variable de parámetro como en esta imagen a continuación:

Esto se debe a que la nueva versión de jenkins requiere que usted defina la variable en el trabajo descendente también. Espero que sea útil.

Simplemente 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 'Execute Shell' y luego pasarla a través de 'Trigger parameterized build on other projects' => 'Predefined parameters" => give 'YOUR_VAR=YOUR YOUR_VAR'. Mi equipo usa esta función para pasar la versión del paquete npm de trabajo de compilación a trabajos de implementación

ACTUALIZACIÓN: arriba solo funciona para Jenkins parámetros inyectados, parámetro creado desde shell todavía necesita usar el mismo método. eg. echo YOUR_VAR = variable{YOUR_VAR} > variable.propiedades y pasar ese archivo downstream

Puedes usar Hudson Groovy builder para hacer esto.

Primer trabajo en pipeline

Segundo trabajo en pipeline

Me enfrenté al mismo problema cuando tuve que pasar una versión pom a un trabajo de Rundeck descendente.

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

1) Creación de propiedades en el archivo de propiedades vía shell:

Acciones de compilación:

• Ejecuta un script de shell
• Inyectar variables de entorno

Ej: definición de propiedades

2) Pasar propiedades definidas al trabajo descendente : Acciones de Post Build :

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

Ej: propiedades que envían

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

/!\ Jenkins Versión: 1.636

/!\ For some reason when creating the triggered build, it was necessary to add the option 'Current build parameters' to pass the propiedad.

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

En estos casos, estoy a favor de 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 desde otra respuesta anterior donde aún se usaban trabajos parametrizados. Esta solución escala muy bien en muchos escenarios.

Ver mi respuesta en este otro post:

Funcionó para mí (El parámetro debe especificarse en ambos trabajos, no solo en el trabajo principal)

Https://stackoverflow.com/a/40348900/2010136