Jenkins - passando variáveis ​​entre empregos?


87

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?


Podemos usar de muitas maneiras: A melhor maneira é usar os parâmetros de trabalho atuais, Ou usar parâmetros predefinidos no trabalho de
recebimento de

1
Este título é tão confuso. Como isso é "passar variáveis ​​entre empregos?". A resposta também aceita é um plugin. Que fantasia!
Rakib

Respostas:


73

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.


10
Oi, desculpe por soar como um novato, mas está tudo bem se alguém pode editar isso com detalhes sobre como fazê-lo com o plug-in acionador parametrizado?
Fadi de

10
Nota lateral: Não parece que as variáveis ​​de ambiente exportadas criadas em seções de script bash são elegíveis para substituição nos parâmetros de saída (por exemplo 'export VERSION' não fará 'UPSTREAM_VERSION = $ VERSION' assumir o valor correto; apenas obtém '$ VERSION' em vez).
Mark McKenna

21
Esta resposta é insuficiente
tarabyte

6
Concordo que deve haver algum tipo de exemplo de como passar os parâmetros para o trabalho de destino. A página atual do plugin de acionamento parametrizado não fornece boas informações sobre isso. Pode haver, por exemplo, que tipo de sintaxe você deve usar ao passar os parâmetros.
Skrii de

2
O plugin parece não funcionar mais. Veja a longa lista de questões em aberto . Não consigo mais passar nenhum valor de parâmetro com este plugin. Alguma outra solução?
Markus L

38

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 :)


Essa resposta satisfaz a pergunta que o OP coloca sem exigir um plug-in ou usar DSL.
BTC

8
Para sua informação, esta resposta ainda precisa do plugin.
Thomas Lee

O plug-in é ótimo quando, mas não pode passar os valores das variáveis ​​definidos nas seções de comando do shell de execução.
Tara Prasad Gurung

25

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


Isso é o que eu precisava. Obrigado.
luckytaxi

Se você deseja usar o pipeline jenkins 2.x, pode usar writeFile / stash-> unstash / readFile para copiar dados de estado entre tarefas. slideshare.net/ericlongtx/… Confira o slide 21 para ver um exemplo.
siesta

Isso é necessário se você deseja que as variáveis ​​SHELL passem. Muito apreciado por esta resposta.
Carl Wainwright

18

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:

insira a descrição da imagem aqui

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.


Concordo plenamente. Esta é uma atualização obrigatória que completa 100% a resposta inicial.
CodeSlave

Eu também tentei as duas opções mais votadas, mas nenhuma delas funcionou até adicionar a configuração extra descrita na etapa 4 acima. Eu não precisava ativar os artefatos de cópia para que funcionasse.
Jeff Fol

10

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

O Build Flow Plugin está obsoleto, os usuários devem migrar para wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin
vhamon

7

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


3

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.


EDIT: Encontrei um erro no que escrevi. Na definição das propriedades, deveria ser: echo POM_VERSION = $ POM_VERSION> play.properties e não: echo $ POM_VERSION >> play.properties Desculpe por isso.
Eli Mous

2

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.



0

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.