APRENDER. PRATICAR. EVOLUIR.A presença não identifica a execução
Um ficheiro de relatório pode sobreviver à falha que devia ter produzido o seu sucessor. No laboratório, a execução A escreve um resultado válido. Um novo processo termina com sete sem tocar nesse ficheiro. O consumidor que só pergunta se pass.json existe recebe uma resposta positiva, mas lê a execução errada. O controlo local compara runId com a execução esperada e devolve run-mismatch. Conserva A como histórico útil; não mudes o campo para B. Numa pipeline real, separa diretórios ou nomes por execução e valida as entradas do consumidor. Esta separação reduz resíduos, mas não substitui resultados funcionais, origem e identidade do candidato.
Identidade do candidato
O laboratório calcula SHA-256 de um ficheiro de texto original denominado candidate.txt. Depois altera os bytes de A para B e compara o relatório anterior com o digest atual. A divergência produz artifact-mismatch, apesar de o nome externo permanecer igual. A comparação deteta associação a bytes diferentes; não conclui que a alteração é maliciosa ou incorreta. Para uma entrega, conserva a ligação entre revisão, artefacto, ambiente e resultados, com o produtor e a execução relevantes. Se precisares de reconstruir ou substituir a candidata, avalia que evidência continua aplicável e quais verificações devem repetir-se. Não atualizes apenas o digest no relatório como se isso tivesse produzido uma nova execução de testes.
O limite deliberado do gate
A última execução passa o gate: runId corresponde, digest corresponde e os dois IDs obrigatórios estão aprovados. Mesmo assim, candidateExecuted é falso. Os testes usam literais e uma conversão de texto; o ficheiro candidato é apenas calculado por hash. Esta diferença é intencional e deve constar da conclusão do aluno. Num projeto real, regista de onde veio o módulo ou serviço exercitado e verifica que corresponde ao alvo da entrega. Uma instalação antiga no ambiente pode responder aos testes enquanto a metadata aponta para uma candidata nova. O laboratório não implementa essa instalação nem a rastreabilidade completa. Demonstra o limite da associação, deixando a prova do alvo real como exercício representativo adicional.
Transporte, apresentação e bloqueio
O relatório local é JSON pedagógico, não JUnit. No cenário adicional GitLab, a documentação oficial distingue a apresentação de resultados JUnit do estado do job: publicar falhas não basta se o script termina com sucesso. Define como conservar diagnóstico sem perder o resultado do produtor e confirma a condição que bloqueia promoção. A configuração de artefactos também determina o que o consumidor recebe; dependencies e needs:artifacts permitem selecionar produtores. Se vários componentes usam report.json, o nome comum não lhes dá o mesmo âmbito. Revê produtores, execução e candidato antes de confiar na entrada recebida. Estes comportamentos GitLab foram estudados na documentação; não houve upload JUnit nem execução de uma pipeline externa neste laboratório.
Confiança e política proporcional
runId e digest são campos declarados, e o laboratório não os assina nem verifica uma identidade externa. Um produtor que possa alterar livremente tudo consegue criar conteúdo autoconsistente. A aprovação real precisa de um percurso de evidência protegido e de uma política adequada ao risco. Também não deves copiar os dois IDs fictícios para todos os projetos. Um teste de permissões Linux pode ser inaplicável em Windows, enquanto a reconciliação permanece obrigatória em ambos. Documenta exclusões por contexto, revê alterações ao inventário e conserva resultados anteriores. Uma exceção legítima não autoriza aceitar todos os skips. Distingue controlos técnicos, decisão de risco e responsáveis para que RUN saiba quando resolver, repetir ou escalar.
Exercício de handover e resumo
Prepara três pacotes para uma oficina: relatório de A apresentado para B, digest divergente e relatório corretamente associado a testes que não carregaram a candidata. Desenvolvimento identifica o alvo exercitado; QA explica o âmbito das verificações; RUN decide quais elementos faltam para avançar. Acrescenta uma variante com um relatório JUnit visível e um script que termina com zero apesar de falhas. Pede uma nota curta com observação, impacto, próximo passo e responsável. O exercício humano ainda não foi executado, e os papéis são fictícios. O laboratório automatizado executou treze grupos locais duas vezes, com onze processos por execução e limpeza da pasta temporária. Resume: preservar histórico, confirmar contexto, verificar alvo e ligar resultados à decisão.
python3 content/labs/cicd-results/run.py --output /tmp/dr-cicd-results-second.json
# old-report-survives-failed-producer: producerExitCode=7
# The old report still says successful=true; gate rejects run-mismatch.
# report-bound-to-other-artifact: gate rejects artifact-mismatch.
# fresh-association-limited-scope: local gate accepts, candidateExecuted=false.
# The JSON report is a teaching format, not JUnit or a signed attestation.
# Two local methods passed; no candidate application was executed.Um relatório antigo permanece num workspace depois de a nova execução falhar; outro tem o hash certo, mas os testes não executaram o ficheiro candidato.
Armadilhas comuns
Aceitar existência ou data como identidade, reescrever runId, confundir publicação JUnit com bloqueio ou tratar um digest como prova de execução e confiança.
Tópicos relacionados: Contratos entre jobs · Evidência de testes · Gestão de releases
A evidência precisa de ser atual, aplicável ao alvo e obtida de um produtor adequado. Um ficheiro legível e autoconsistente ainda pode não sustentar a decisão.
Referência: Job artifacts · CI/CD practices 2026-09; scoped GitHub Actions GitLab Jenkins and Azure DevOps Services documentation