Executando verificação de segurança...
3

Bem legal a investigação, parabéns. Eu só discordo em falar que a culpa era do dev novato. Ele teve culpa por ter editado um yaml que não deveria (E isso ainda é passível de questionamento, pois onde tava a review do PR ?), mas no geral a culpa foi do pipeline. Já que exitem pontos não mapeados sobre as ações que fazem o pipeline executar, então o agente deveria verificar resíduos antes da instalação do angular. Na minha opinião, penso que a pipeline deveria ser revisada, pois não faz sentido qualquer cancelamento da execução provocar um erro que causa problema nos próximos builds.

No mais, entendo que processos se distinguem de um local para outro, mas o PR é um ponto de revisão e mudanças. Não acredito ter sentido o dev ter que garantir que esteja tudo ok no PR, pois tudo ali é passível de alterações.

Carregando publicação patrocinada...
2

Fala, clovisdanielss! Cara, excelente ponto.

Concordo 100% com você, e refletindo sobre seu comentário vi que posso ter me expressado mal no final... Quando eu disse que a 'culpa' não era dele, foi justamente nesse sentido: o comportamento de atualizar uma PR é esperado e legítimo (até por que se não fosse não teria essa possibilidade né? haha). O sistema é que foi frágil ao não lidar com o estado residual no disco. O bug é sistêmico, não humano.

O aprendizado real foi que a pipeline precisa ser resiliente (inclusive deixei isso em aberto no final do artigo... aquele step de limpeza antes do npm install acredito que resolve exatamente isso). E o melhor, esse caso foi um dos gatilhos para eu mudar a estratégia: hoje rodamos tudo em Kubernetes com pods efêmeros. Cada build roda num container limpo, então resíduos de builds anteriores nem existem mais. Problema eliminado pela raiz xD

Valeu demais pelo feedback, agrega muito na discussão de como tornar o CI mais resiliente!