O Que É Fan-Out / Fan-In?
O fan-out espalha o trabalho por muitos jobs paralelos; o fan-in coleta todas as saídas deles de volta em um único job downstream.
Muitos pipelines têm um formato natural: um job prepara as coisas, muitos jobs fazem trabalho em paralelo, e um job agrega os resultados. O fan-out é o espalhamento; o fan-in é a reunião. É a espinha dorsal dos testes com sharding e dos builds com matrix.
O padrão
- Fan-out: um job de build ou setup dispara N jobs paralelos (shards, células de matrix).
- Fase paralela: cada job faz sua fatia de forma independente.
- Fan-in: um job final espera por todos eles e combina os resultados.
Um pequeno exemplo
Um job de build faz fan-out para quatro shards de teste via uma matrix; um job report lista os quatro shards em seu needs para que rode apenas depois que eles terminarem, então baixa o artifact de cada shard e publica um único resultado com merge.
Por que o job de fan-in importa
O job de fan-in depende de cada job paralelo, então só roda quando todos eles terminam. É onde você faz o merge da cobertura, publica um report combinado ou condiciona um deploy à aprovação de todo o conjunto.
Run-on-failure para relatórios
Configure o job de relatório de fan-in para rodar mesmo quando um job paralelo falhou (por exemplo if: always()). Caso contrário, você perde o report agregado exatamente nas execuções em que mais precisa ver o que quebrou.
Armadilhas comuns
Um trabalho de fan-out desigual significa que o fan-in espera pelo branch mais lento, apagando o benefício do paralelismo. E esquecer um job paralelo nas dependências do fan-in deixa que ele rode antes daquele job terminar, produzindo um resultado parcial.
Principais conclusões
- O fan-out espalha o trabalho para jobs paralelos; o fan-in agrega os resultados deles.
- O job de fan-in depende de todos os jobs paralelos e roda depois que eles terminam.
- Faça o fan-in de relatório rodar em caso de falha para que você mantenha o report combinado.