Jenkins - passando variáveis ​​entre empregos?

Tenho dois empregos no Jenkins, ambos precisam do mesmo parâmetro.

Como posso executar o primeiro trabalho com um parâmetro para que, ao acionar o segundo trabalho, o mesmo parâmetro seja usado?

Você pode usar o plugin de acionamento parametrizado, que permitirá que você passe parâmetros de uma tarefa para outra.

Você também precisa adicionar este parâmetro que você passou do upstream no downstream.

1.Post-Build Actions> Select ”Trigger parametrizado build em outros projetos”

2. Insira a variável de ambiente com value.Value também pode ser Jenkins Build Parameters.

As etapas detalhadas podem ser vistas aqui: -

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

Espero que seja útil :)

A resposta aceita aqui não funciona para meu caso de uso. Eu precisava ser capaz de criar parâmetros dinamicamente em um trabalho e passá-los para outro. Como Mark McKenna menciona, aparentemente não há maneira de exportar uma variável de uma etapa de construção do shell para as ações pós-construção.

Consegui uma solução alternativa usando o plugin de acionamento parametrizado , gravando os valores em um arquivo e usando esse arquivo como os parâmetros para importar por meio de 'Adicionar ação pós-compilação' -> 'Acionar compilação parametrizada ...' e selecionando 'Adicionar parâmetros' - > 'Parâmetros do arquivo de propriedades'.

Acho que a resposta acima precisa de alguma atualização:

Eu estava tentando criar um diretório dinâmico para armazenar meus artefatos de compilação de upstream, então queria passar meu número de compilação de trabalho de upstream para o trabalho de downstream. Tentei as etapas acima, mas não consegui fazer funcionar. Funcionou assim:

1. Copiei os artefatos do meu trabalho atual usando o plugin de artefatos de cópia.
2. Na ação de pós-construção do trabalho upstream, adicionei a variável como "SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}" e configurei para acionar o trabalho downstream.
3. Tudo funcionou, exceto que meu trabalho downstream não foi capaz de obter $ SOURCE_BUILD_NUMBER para criar o diretório.
4. Então eu descobri que para usar essa variável eu tenho que definir a mesma variável no trabalho de downstream como uma variável de parâmetro como na imagem abaixo:

Isso ocorre porque a nova versão de jenkins exige que você defina a variável no trabalho de recebimento de dados também. Espero que seja útil.

(para outros googlers)

Se você estiver construindo um pipeline sério com o Build Flow Plugin , poderá passar parâmetros entre jobs com a DSL como este:

Supondo um parâmetro de string disponível "CVS_TAG", a fim de passá-lo para outras tarefas:

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'])

Dica para exibir variáveis ​​/ parâmetros disponíveis:

// 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 '------------------------------------'

Basta adicionar minha resposta além da de Nigel Kirby, pois ainda não posso comentar:

Para passar um parâmetro criado dinamicamente, você também pode exportar a variável no bloco 'Executar Shell' e, em seguida, passá-la por 'Acionador de compilação parametrizada em outros projetos' => 'Parâmetros predefinidos "=> dar' YOUR_VAR = $ YOUR_VAR '. Minha equipe usa este recurso para passar a versão do pacote npm do trabalho de construção para trabalhos de implantação

ATUALIZAÇÃO: acima só funciona para parâmetros injetados no Jenkins, parâmetro criado a partir do shell ainda precisa usar o mesmo método. por exemplo. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties e passe esse arquivo downstream

Eu enfrentei o mesmo problema quando tive que passar uma versão de pom para um trabalho Rundeck downstream.

O que fiz foi usar injeção de parâmetros por meio de um arquivo de propriedades como:

1) Criação de propriedades no arquivo de propriedades via shell:

Ações de construção:

• Execute um script de shell
• Injetar variáveis ​​de ambiente

Por exemplo : definição de propriedades

2) Passando as propriedades definidas para o trabalho downstream: Ações pós-construção:

• Trigger parametrizado em outro projeto
• Adicionar parâmetros: parâmetros de construção atuais
• Adicionar parâmetros: parâmetros predefinidos

Por exemplo : envio de propriedades

3) Foi então possível usar $ POM_VERSION como tal no trabalho Rundeck downstream.

/! \ Jenkins Versão: 1.636

/! \ Por algum motivo ao criar a compilação acionada, foi necessário adicionar a opção 'Parâmetros de compilação atuais' para passar as propriedades.

Lendo as respostas, não vejo outra opção de que goste, então também a oferecerei. Eu amo a parametrização de jobs, mas nem sempre escalona bem. Se você tiver trabalhos que não estão diretamente no fluxo do primeiro trabalho, mas mais abaixo no pipeline, você realmente não deseja parametrizar todos os trabalhos no pipeline para poder passar os parâmetros por completo. Ou se você tiver um grande número de parâmetros usados ​​por uma variedade de outros trabalhos (especialmente aqueles não necessariamente vinculados a um trabalho pai ou mestre), novamente a parametrização não funciona.

Nesses casos, sou a favor da saída dos valores para um arquivo de propriedades e, em seguida, injetá- los em qualquer trabalho de que preciso usando o plug- in EnvInject . Isso pode ser feito dinamicamente, que é outra maneira de resolver o problema de outra resposta acima, onde trabalhos parametrizados ainda eram usados. Essa solução se adapta muito bem em muitos cenários.

Você pode usar o construtor Hudson Groovy para fazer isso.

Primeiro trabalho no pipeline

Segundo trabalho no pipeline

Eu descobri!

Com quase 2 horas de tentativa e erro, descobri.

Isso FUNCIONA e é o que você faz para passar variáveis ​​para o trabalho remoto:

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

Use \ n para separar dois parâmetros, sem espaços ..

Ao contrário dos parâmetros: '' 'someparams' ''

usamos parâmetros: "someparams"

o "..." é o que nos dá os valores das variáveis ​​desejadas. (Estas são aspas duplas, não duas aspas simples)

o '' '...' '' ou '...' não nos trará esses valores. (Três aspas simples ou apenas aspas simples)

Todos os parâmetros aqui são definidos no bloco de ambiente {} no início do pipeline e são modificados em estágios> etapas> scripts sempre que necessário.

Eu também testei e descobri que quando você usa "..." você não pode usar algo como '' '... "..."' '' ou "... '..'..." ou qualquer combinação de isto...

O problema aqui é que quando você está usando "..." na seção de parâmetros, você não pode passar um parâmetro de string; por exemplo, isto NÃO FUNCIONARÁ:

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

se você quiser passar algo como o acima, você precisará definir uma variável de ambiente param2 = 'param2' e então usar $ {env.param2} na seção de parâmetros da etapa do plugin de gatilho remoto