Definir a decisão antes de interpretar a cor
Uma release fictícia de fundos exige o artefacto aprovado, testes unitários e de integração e uma cópia recuperável durante trinta dias. Estas são condições do exercício, não regras universais Jenkins ou de um banco. Começa por escrever que evidência satisfaz cada condição e quem pode aceitar uma exceção. O estado global do build é útil, mas resulta do desenho da pipeline e das opções dos passos. Um fluxo pode continuar depois de uma falha tratada ou sem um relatório esperado. O responsável técnico precisa de explicar o que efetivamente executou, sobre que objeto e com que resultado, antes de recomendar a passagem a operação.
Relacionar o job dependente com a execução certa
Quando um job chama outro, conserva a identidade da execução dependente e o artefacto que recebeu. WaitForStart espera pelo início, não pela conclusão. Propagate false permite que o chamador trate explicitamente o resultado; não é uma aprovação do trabalho dependente. A referência documenta valores por omissão diferentes para propagate em build e waitForBuild, pelo que a intenção deve ficar explícita. No caso da aula, o produtor 410 criou A, mas a integração 88 recebeu B através de latest. Mesmo um SUCCESS real na integração não valida A. A primeira decisão é reconciliar a identidade e obter resultados para o objeto aprovado.
Interpretar erros sem perder a intenção de parar
Um comando pode devolver um código não zero através de returnStatus, deixando ao script a responsabilidade de decidir. Guardar esse número sem o utilizar não resolve a falha. Da mesma forma, um catchError amplo precisa de distinguir uma falha recuperável de uma interrupção que deve parar o fluxo; catchInterruptions false volta a lançar essas interrupções. Antes de ajustar resultados para manter a pipeline em execução, descreve o motivo operacional. Pode ser necessário recolher diagnóstico após uma falha, sem permitir promoção. O resultado do build também não pode ser melhorado de UNSTABLE para SUCCESS através de buildResult no catchError. Manter o histórico evita transformar tratamento de erros em perda de evidência.
Publicar testes e reconhecer evidência ausente
JUnit publica resultados produzidos pela ferramenta de testes. Um XML em falta exige investigação quando a suite é obrigatória. AllowEmptyResults permite que essa ausência não altere o estado do build, mas não executa testes nem autoriza uma exclusão. Há ainda opções que separam a marcação de instabilidade do build e do stage; por isso, lê os resultados e a configuração em conjunto. Na oficina, compara a lista esperada de suites com a lista observada para a mesma identidade de artefacto. Distingue ausência, falha e teste ignorado. Não uses a soma de testes unitários para substituir silenciosamente uma suite de integração que verifica outro tipo de risco.
Separar rastreabilidade de retenção
Um fingerprint ajuda a relacionar ficheiros produzidos e usados quando os projetos envolvidos registam essa informação. A base guarda checksums e utilizações, não uma cópia do binário; também não substitui uma assinatura de confiança. ArchiveArtifacts trata outra necessidade: guardar ficheiros do workspace. Se allowEmptyArchive permitir zero ficheiros, o aviso não demonstra que existe um pacote recuperável. Define uma política de retenção compatível com o período de suporte e confirma uma recuperação de ensaio. Num exercício em que o pacote expira ao fim de sete dias mas pode ser necessário no dia vinte, a rastreabilidade perfeita continua sem resolver a falta da cópia.
Oficina e resumo para a passagem a operação
Usa os dados sintéticos do laboratório para avaliar três candidatos: A sem teste de integração, B com testes mas fora da autorização e A com todas as suites e retenção suficiente. O modelo aplica apenas a política fictícia descrita; não executa Jenkins, plugins ou deployments. Regista para cada candidato os motivos concretos que impedem promoção. Depois prepara uma passagem de turno com execução produtora, execução de testes, identidade do artefacto, suites, falhas, exclusões e localização da cópia recuperável. Relaciona esta evidência com os responsáveis pela decisão e o prazo da alteração. O resumo final deve permitir ao colega reproduzir o raciocínio sem depender apenas da cor de um painel.
Contexto da LTS 2.580.1 e plugins
A página de downloads e o changelog consultados em 2 de outubro identificam a LTS 2.580.1, publicada em 30 de setembro de 2026. A política de runtime continua a indicar Java 21 ou 25. Os exercícios anteriores do percurso conservam a sua baseline 2.568.3. O guia da nova LTS explica que alguns plugins já separados do core deixaram de acompanhar o WAR. Numa instalação sem acesso ao update center, prepara explicitamente as dependências necessárias antes da atualização; não presumas que copiar o WAR inclui os plugins de publicação de testes. O caso de atualização direta de versões muito antigas tem condições próprias. Esta aula não executou nem certificou essa migração.
// Conceptual Jenkins Pipeline fragment; not executed by the local model.
// Validate installed plugin versions and the project's own acceptance policy.
def downstream = build job: 'integration', wait: true, propagate: false
if (downstream.result != 'SUCCESS') {
error('Integration outcome requires review')
}
// Also verify artifact identity, mandatory suites and recoverable retention.
// A SUCCESS result alone does not establish those additional conditions.O produtor 410 gerou A, mas a integração 88 testou B através de latest. O resultado de B não demonstra a aceitação de A.
Armadilhas comuns
Confundir início com conclusão; ignorar result ou returnStatus; aceitar XML ausente; usar fingerprints como cópia do binário.
Tópicos relacionados: Pipeline: âmbito, tempo e evidência · Entrega, aprovações e repetição · Upgrades, backups e recuperação
A promoção precisa de evidência para o artefacto aprovado e de critérios explícitos. Um build verde, isoladamente, não demonstra esses requisitos.
Referência: Pipeline Build Step · Jenkins LTS 2.568.3 historical exercises; LTS 2.580.1 documentation reviewed 2026-10-02; Java 21 or 25 runtime; plugin versions require confirmation