APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Recolher resultados e aplicar critérios são responsabilidades relacionadas, mas diferentes. Um comando pode falhar e a pipeline continuar para publicar o relatório; isso é útil se a falha continuar visível e impedir promoção indevida. Em Jenkins, o passo junit pode marcar a build UNSTABLE. Se o shell foi configurado para devolver sucesso apesar de falhas, as etapas seguintes precisam de considerar o resultado registado. Caso contrário, uma decisão importante foi removida sem intenção. Não confies apenas na cor de uma etapa ou no último exit code. Identifica que teste correu, sobre que artefacto, com que resultado e qual a regra que autoriza continuar.
Aplicação guiada
Num exemplo fictício, a integração falha na reconciliação de um ficheiro financeiro. Reexecutar até obter verde não explica a falha nem demonstra estabilidade. Preserva logs sem dados sensíveis, compara ambiente e entradas e atribui investigação. Se houver exceção temporária, explicita âmbito, risco, autoridade e data de revisão em vez de esconder o teste. Mantém distinção entre erro de infraestrutura e defeito da aplicação. Em Azure DevOps Services, aprovações e checks dos recursos são geridos fora do YAML por quem administra esses recursos; editar o ficheiro da pipeline não altera diretamente esses controlos. A etapa precisa de satisfazer os checks dos recursos consumidos. Aprovação humana também não substitui testes que continuam a falhar.
Relatório de teste publicado com UNSTABLE não equivale a critérios de promoção cumpridos.
Armadilhas comuns
Suprimir exit code como correção; retry até verde; aprovação como substituto de evidência.
Tópicos relacionados: Integração e entrega · Jobs e dependências · Artefactos e evidência
Conserva diagnóstico e mantém o resultado do teste ligado à decisão de avançar.
Referência: Test result handling artifacts and credential scope · CI/CD practices 2026-09; scoped GitHub Actions GitLab Jenkins and Azure DevOps Services documentation