Introdução
Walk Weekender confirmou uma edição de seu pacote para visitantes do Riverwalk Saturday. Um rascunho posterior também foi gerado com sucesso. O job de entrega deve obter o pacote confirmado de sua execução existente no Jenkins, sem reconstruí-lo nem depender de um workspace que já foi limpo.
Este laboratório pressupõe os conceitos de arquivamento, limpeza do workspace e fingerprints ensinados em Mantenha um pacote de evento disponível para download, além de navegação básica no Jenkins e extração de ZIP. Esta unidade começa de forma independente: seu histórico de origem, o pacote atual anterior e o job de entrega já estão preparados. Você não precisa de arquivos nem de uma VM em execução do laboratório anterior.
Use Pack Desk para examinar os arquivos reais para visitantes e Jenkins para examinar e configurar jobs. São dois serviços em uma única VM preparada. O plugin Copy Artifact já está disponível. O publicador fornecido é um pequeno receptor local de treinamento que verifica esta solicitação; ele não é um registro de artefatos de produção nem um serviço de aprovação. Você selecionará uma execução já confirmada, sem implementar um processo de aprovação. A duração é uma estimativa do autor, e não um tempo medido com iniciantes.
Compare a solicitação com o pacote copiado
Nesta etapa, você identificará a execução de origem confirmada e depois observará um job de entrega copiar uma edição diferente. Comece em Pack Desk.
Leia Requested edition: RW-02. A atividade é Riverwalk Saturday, e o job de origem é create-riverwalk-pack. Selecione Open the current pack. A edição atual é RW-01, com horário de encontro às 10:30. O pacote solicitado deve substituir essa edição anterior, enquanto o pacote separado do Parkside continua disponível. Use a ação Back do navegador para voltar ao painel.
Mude para Jenkins, abra create-riverwalk-pack e examine seus builds numerados em Builds. Os números de build pertencem a um job; um número isolado não é uma identidade global de artefato. Abra Console Output de cada build para ler a edição preparada para visitantes e o resultado final. O histórico contém:
| Build | Edição para visitantes | Resultado | Significado para esta solicitação |
|---|---|---|---|
| #1 | Parkside Paper Trail / PP-01 | SUCCESS | Uma atividade diferente |
| #2 | Riverwalk Saturday / RW-02 | SUCCESS | O pacote confirmado existente |
| #3 | Riverwalk Saturday / RW-03-DRAFT | SUCCESS | Um rascunho mais recente, não o solicitado |
| #4 | Riverwalk Saturday / RW-02 | FAILURE | Uma execução malsucedida, embora tenha retido um ZIP |
Abra o build #2 usando seu link na trilha de navegação, baixe event-pack.zip em Build Artifacts e extraia o arquivo compactado completo. Sua visão geral e suas notas mostram RW-02 e 10:00. Seu console termina com a limpeza do workspace. O arquivo compactado pertence ao build, portanto o job de entrega pode obtê-lo após essa limpeza.
Mantenha esse histórico de origem existente. Não configure, execute novamente, exclua nem renomeie os jobs de origem ou seus builds. Apenas o Pipeline de deliver-riverwalk-pack e seus parâmetros de build estão no escopo. Mantenha os arquivos fornecidos, o publicador, o arquivamento e a limpeza, e deixe o pacote separado do Parkside intacto.
Use Dashboard na trilha de navegação, abra deliver-riverwalk-pack e selecione Configure e a seção Pipeline. Leia o estágio Copy archive sem alterá-lo ainda:
copyArtifacts projectName: params.SOURCE_JOB,
selector: lastSuccessful(),
filter: 'event-pack.zip',
fingerprintArtifacts: true
copyArtifacts obtém artefatos retidos de outro job do Jenkins. projectName seleciona esse job; params.SOURCE_JOB lê o valor informado para esta execução de entrega. filter escolhe arquivos dentro de seu arquivo de artefatos. O seletor decide qual execução numerada de origem usar. lastSuccessful() é uma seleção variável: significa a execução bem-sucedida mais recente no momento em que a cópia ocorre, e não a edição da sua solicitação. fingerprintArtifacts: true registra o uso do arquivo para rastreamento entre jobs.
O estágio Archive delivery fornecido retém o ZIP copiado no build de entrega. Deliver pack envia exatamente esses bytes copiados ao painel local. A limpeza final em post limpa o workspace de entrega. Mantenha essas partes inalteradas. Selecione Save sem editar.
Selecione Build with Parameters. Aguarde o formulário terminar de carregar. Defina SOURCE_JOB como create-riverwalk-pack e SOURCE_BUILD como 2 e selecione Build. Esses valores descrevem a origem pretendida; o seletor atual ainda ignora SOURCE_BUILD.
Aguarde esse build de entrega terminar com FAILURE e abra Console Output. Espere ver Copied 1 artifact do build de origem 3, seguido de The package bytes differ from the selected source archive. O publicador retorna HTTP 422: o serviço foi alcançado, mas rejeitou o pacote selecionado. Isso é diferente de uma falha de conexão. A etapa de shell informa um resultado diferente de zero, por isso o build falha.
Abra o event-pack.zip desse build de entrega em Build Artifacts, extraia-o para uma pasta separada e leia sua visão geral. Ele contém RW-03-DRAFT, porque o build #3 é a última execução de origem bem-sucedida. Um ZIP retido e uma execução de origem verde são insuficientes para identificar a edição solicitada.
Mude para Pack Desk, atualize a página e abra o pacote atual novamente. Ele ainda deve mostrar RW-01 e 10:30. A tentativa rejeitada não deve substituir materiais válidos para visitantes. Volte ao painel com a ação Back do navegador.
Entregue e rastreie a execução confirmada
Nesta etapa, você copiará a execução confirmada selecionada explicitamente e verificará os arquivos entregues para visitantes e seu rastreamento no Jenkins. Comece na página do job deliver-riverwalk-pack em Jenkins.
Selecione Configure e depois Pipeline. Em Script, altere apenas:
selector: lastSuccessful(),
para:
selector: specific(params.SOURCE_BUILD),
specific(...) seleciona um número explícito de build de origem. params.SOURCE_BUILD lê a string informada no formulário de build; junto com SOURCE_JOB, ela identifica uma execução existente. Mantenha a vírgula: a configuração filter seguinte pertence à mesma operação copyArtifacts. Mantenha o valor de RECEIVER_URL fornecido, todos os outros estágios e a limpeza final.
Em Script, localize a linha do seletor em Copy archive. Aguarde o código terminar de carregar e role dentro do editor se necessário. Dê um clique duplo em lastSuccessful para selecionar apenas esse nome de função e digite specific. Os parênteses vazios permanecem. Com o cursor imediatamente após specific, pressione a tecla Right Arrow uma vez para entrar em () e digite params.SOURCE_BUILD. Confira a linha completa do seletor acima antes de salvar. Se você substituir mais texto por engano, use Ctrl+Z no Windows/Linux ou Command+Z no macOS antes de salvar e tente novamente. Selecione Save.
Execute Build with Parameters novamente. Aguarde o formulário terminar de carregar, informe create-riverwalk-pack em SOURCE_JOB e 2 em SOURCE_BUILD e selecione Build. Aguarde SUCCESS. Seu console deve mostrar o artefato copiado, as ações de arquivamento e fingerprint, uma resposta contendo delivered e a limpeza final do workspace.
Se o Jenkins informar um erro de sintaxe do Groovy, volte a Configure e confira a linha do seletor, os parênteses e a vírgula com a substituição exata acima. Salve e execute novamente com os mesmos valores. Se o console informar que um projeto, build ou artefato não foi encontrado, confira os dois valores do formulário e o build de origem #2. Não execute novamente o job de origem para fabricar uma nova execução. Uma resposta dizendo The selected source run does not satisfy this delivery request. significa que o job ou o número de build está errado. The package bytes differ from the selected source archive. significa que o ZIP copiado não corresponde à execução de origem indicada por esses parâmetros. Ambas são recusas por regras de negócio após alcançar o painel.
Abra a página de status do build de entrega bem-sucedido e selecione See Fingerprints. Em Recorded Fingerprints, Original owner na linha de event-pack.zip deve levar ao build #2 de create-riverwalk-pack. Selecione o link event-pack.zip para abrir seus detalhes. O link do build em que o arquivo foi introduzido deve identificar essa execução de origem, e Usage deve incluir sua execução bem-sucedida de deliver-riverwalk-pack. Esses são os registros do Jenkins sobre a origem e o uso do mesmo arquivo. Eles não certificam quem aprovou uma edição nem fornecem uma assinatura criptográfica do publicador.
Leia o link do build em que o arquivo foi introduzido perto do topo e os dois jobs em Usage. O número do seu build de entrega pode ser diferente do exemplo.
Baixe event-pack.zip desse build de entrega bem-sucedido. Extraia-o para uma nova pasta, abra index.html e confirme Riverwalk Saturday, RW-02 e 10:00. Abra Explore the route e confira as três paradas e a imagem renderizada do percurso. Selecione Download all route stops para o CSV e Read the visitor notes para o texto local. As notas podem abrir diretamente no navegador em vez de iniciar outro download; o arquivo de texto original já está na pasta extraída. Mantenha os oito arquivos juntos, incluindo build.json, cujos campos job e number identificam create-riverwalk-pack e 2.
Mude para Pack Desk e atualize a página. O pacote atual agora deve mostrar RW-02. Abra-o e repita as verificações do percurso, do CSV e das notas. Volte com a ação Back do navegador e selecione Download the current ZIP. Esse download deve ser o arquivo compactado original completo da origem, e não um substituto recém-reconstruído. O receptor compara os bytes reais antes de alterar o pacote atual.
Por fim, selecione Parkside pack na navegação do painel e confirme que Parkside Paper Trail ainda abre com seu percurso e suas notas. O histórico de builds de origem e todos os arquivos fornecidos devem permanecer intactos. Após qualquer outra edição do Pipeline, execute novamente o Pipeline salvo antes de verificar a conclusão.
Resumo
Você obteve um pacote confirmado para visitantes de um build existente do Jenkins depois que seu workspace foi limpo. Você viu por que um seletor variável podia escolher um rascunho bem-sucedido, usou um job e um número de build explícitos e acompanhou o arquivo compactado original pelas fingerprints do Jenkins até um job de entrega separado. O painel agora disponibiliza os arquivos originais completos para visitantes, enquanto a atividade separada continua disponível.
