APRENDER. PRATICAR. EVOLUIR.Observar a falha escondida por tee
O primeiro grupo Bash executa um produtor que imprime assertion failed e termina com sete, ligado a tee para escrever report.txt. Sem pipefail, o processo devolve zero; com pipefail, devolve sete. O relatório permanece nas duas situações. A execução registada usa Bash 3.2.57 do host Darwin, com opções explícitas; não representa a versão de um runner GitHub atual. A documentação de GitHub distingue a invocação de shell e aplica pipefail quando se escolhe shell: bash. No diagnóstico real, verifica o comando efetivo, incluindo wrappers. Não concluas pelo ficheiro existente que o teste passou. A evidência de transporte e a evidência do resultado respondem a perguntas diferentes.
Guardar o diagnóstico sem apagar o erro
O segundo grupo compara dois scripts curtos. O primeiro usa || true depois de uma falha e termina com uma mensagem, devolvendo zero. O segundo guarda o código sete, escreve um relatório e termina com esse código guardado. O ficheiro fica disponível e a falha mantém-se observável. Este padrão local ensina a intenção; numa pipeline real, confirma também como a plataforma executa steps posteriores e publica artefactos quando há falhas. Não basta adicionar uma etapa de upload se nunca for alcançada. Inversamente, permitir recolha de diagnóstico não deve autorizar automaticamente a entrega. Define separadamente a condição de publicar evidência e a condição de promover o candidato.
Distinguir o resultado da política de continuação
Em GitHub Actions, outcome e conclusion permitem distinguir o resultado original de um step do efeito de continue-on-error. Quando o step falha com essa opção, outcome pode indicar failure e conclusion success. Essa distinção consta da documentação consultada; não foi executada num runner neste laboratório. Usa-a para rever um controlo crítico que só olha para a conclusão final. Continuar pode ser útil para recolher relatórios ou avaliar outros componentes, mas a política precisa de decidir explicitamente como tratar a falha. Num exercício fictício, pede à equipa que identifique quem pode aceitar uma exceção, que impacto é conhecido e qual evidência permanece registada. Não reescrevas o passado para obter verde.
Transmitir dados entre processos com um contrato
O terceiro grupo exporta DR_RELEASE_ID num processo e confirma demo-42. Um segundo processo, iniciado com ambiente limpo, obtém unset. Depois, o laboratório grava release_id=demo-42 num ficheiro local indicado por GITHUB_OUTPUT. A escrita está verificada, mas nenhum runner leu o ficheiro. Não transformes esta observação numa alegação de execução de outputs GitHub. Na plataforma, é necessário respeitar o contrato de step, publicação no job e consumo pelo contexto adequado. Escolhe também o mecanismo certo: um identificador pequeno não tem o mesmo ciclo de vida de um binário ou relatório. Regista origem, consumidor e retenção necessária para evitar dependências acidentais no estado de uma máquina.
Preservar dados literais e identidade do artefacto
O quarto grupo passa um título benigno com aspas, ponto e vírgula e asterisco por uma variável de ambiente. printf com quoting devolve o texto intacto; não há eval ou interpolação de código do evento. No mesmo grupo, release.txt passa de validated-release-42 para rebuilt-release-42 e o SHA-256 muda. O nome permanece, mas a igualdade de conteúdo falha. O ensaio não verifica assinatura ou proveniência de um produtor. Usa estas duas observações para separar representação e significado: um texto deve continuar a ser dado, e um nome estável não deve substituir identidade do candidato. Antes de promover uma reconstrução, confirma a evidência aplicável aos novos bytes e ao destino previsto.
Ensaiar a decisão antes da janela
Reserva o final da oficina para o caso do relatório do run 41 associado ao candidato A, copiado para uma entrega de B no run 42. Escreve a decisão e o que a faria mudar. Um upload bem-sucedido prova transferência, não validação de B. Podes propor recuperar A apenas se continuar adequado ao estado e ao destino e existir decisão responsável. Depois revê os limites do laboratório: análise local de oito ficheiros, quatro grupos Bash e ficheiros temporários, sem provider externo ou deployment. A revisão independente e a prática numa plataforma autorizada continuam necessárias. Conserva os exemplos negativos para detetar regressões quando atualizares o linter, sem assumir que qualquer versão futura produz diagnósticos idênticos.
check_status=0
# Original local demonstration: a deliberately failing check
(exit 7) || check_status=$?
printf "failed-check=7\n" > retained-report.txt
exit "$check_status"
# Observed: report remains; process exits 7
# This is not a complete production pipeline.Um job fictício está verde porque tee terminou bem, embora o teste tenha falhado. A equipa precisa de guardar o diagnóstico e bloquear a promoção.
Armadilhas comuns
Usar || true sem conservar o resultado, assumir ambiente global entre jobs, confundir ficheiro de output com processamento pelo runner e nome de artefacto com identidade dos bytes.
Tópicos relacionados: Bash e Linux · Observabilidade · Gestão de mudanças
Recolher diagnóstico pode continuar depois de uma falha. A decisão de entrega deve continuar ligada ao resultado crítico e ao candidato efetivamente validado.
Referência: Workflow syntax for GitHub Actions · CI/CD practices 2026-09; scoped GitHub Actions GitLab Jenkins and Azure DevOps Services documentation