4 Padrões de GitHub Actions para ETL em Monorepo
Rodar três sites a partir de um único monorepo cria problemas. Você enfrenta três jobs de ETL separados, três reconstruções de conteúdo e três pipelines de implantação. Se você não os coordenar, eles colidem.
Passei seis semanas testando cronogramas para estabilizar essa configuração. Aqui estão os quatro padrões que utilizo.
- Use Deslocamentos de Tempo (Time Offsets) para Cron Jobs
Rodar todos os jobs de ETL ao mesmo tempo causa falhas. Os jobs competem por limites de taxa (rate limits) de API. Quando o HuggingFace ou o GitHub retorna um erro 429, a execução falha.
Eu utilizo deslocamentos de 30 minutos para evitar isso.
- O primeiro job começa às 02:00
- O segundo job começa às 02:30
- O terceiro job começa às 03:00
Trinta minutos é tempo suficiente para finalizar uma extração pesada antes que o próximo job comece. Isso mantém seus logs limpos e evita colisões de API.
- Use Flags de Skip para Interromper Reconstruções Desnecessárias
Todo job de ETL termina com um deployment na Vercel. Um problema surge quando commits de artigos também disparam reconstruções. Sem um plano, cada atualização de artigo força a reconstrução dos três sites. Isso desperdiça minutos de build.
Eu utilizo uma tag [skip publish-articles] nas mensagens de commit do ETL.
Adicionei uma etapa no meu workflow para verificar essa flag. Se a tag existir, o workflow pula a etapa de build e deploy. Isso mantém os pipelines de ETL separados dos pipelines de artigos.
- Use Filtros de Caminho (Path Filters) para Alvos em Sites Específicos
Você não quer que a atualização de um site dispare três deployments. Eu configuro o workflow de cada site para observar apenas sua própria pasta e a pasta de pacotes compartilhados.
Lógica de exemplo:
- O site de ferramentas de IA observa apenas
apps/ai-tools/ - O site de OSS observa apenas
apps/oss-alternatives/
Se você alterar o código no diretório compartilhado, todos os sites serão reconstruídos. Eu aceito essa compensação (trade-off) porque mudanças em código compartilhado são raras.
- Adicione Dispatch Manual para Controle
O Cron cuida da rotina diária. O dispatch manual cuida de todo o resto. Eu utilizo workflow_dispatch para poder:
- Reexecutar um job de ETL que falhou
- Forçar uma atualização após adicionar dados
- Executar um dry run para testar dados sem gravá-los no banco de dados
A interface do GitHub mostra um menu suspenso para essas escolhas. Isso evita erros de digitação e facilita o debugging.
Resumo
Esses padrões não são complexos. Eles são explícitos. Eu mantenho um arquivo markdown simples no meu repositório para documentar essas regras. Isso garante que eu não quebre o sistema ao adicionar novos workflows.