O sofrimento causado pelo GitHub Actions

• Problemas do GitHub Actions

  • Recentemente, foi gasto muito tempo reescrevendo scripts de CI com GitHub Actions. Antes era usado o Earthly, mas como foi descontinuado, houve um retorno ao GitHub Actions.
  • CI é complexo e inclui fila de merge, vários runners, builds em Rust, imagens Docker, testes de integração etc. Cada merge de PR consome muito tempo de CI.
  • Como boa prática de software, todos os testes devem passar, erros triviais devem ser corrigidos automaticamente e os artefatos testados devem ser idênticos aos da release. O GitHub Actions permite isso, mas a configuração é complexa e inconsistente.

• Verificações de status e fila de merge

  • A fila de merge do GitHub executa o CI depois de fazer rebase do PR na branch principal. Porém, é preciso rodar o CI tanto antes quanto depois de entrar na fila, e configurar isso é difícil.
  • A solução é definir o mesmo nome de job nas duas etapas. Assim, ambas precisam passar.

• Problemas de segurança

  • Recentemente, uma GitHub Action popular foi comprometida. Como resposta, recomendou-se fixar dependências por hash, mas a maioria dos usuários não faz isso.
  • O modelo de segurança do GitHub é complexo e difícil de entender. É possível definir as permissões padrão do GITHUB_TOKEN, mas não é claro como remover permissões.
  • As permissões do workflow não dependem da action em si, e elevar permissões dentro do código parece algo estranho.

• A combinação de Docker e GitHub Actions

  • No GitHub Actions é possível executar tarefas dentro de contêineres, mas isso causa problemas como permissões de arquivos e mudança da localização do diretório $HOME.
  • O campo de contêiner tem muitas limitações, o que impede sobrescrever o entrypoint ou executar apenas algumas etapas dentro do contêiner.

• Desenvolvimento de workflows em YAML

  • Escrever lógica em YAML pode ficar complexo e é fácil cometer erros. Foi usado o IDE RustRover para fazer algumas verificações, mas são necessárias análises estáticas melhores.
  • É difícil testar localmente, então é preciso criar um repositório equivalente e repetir commits e pushes até o CI funcionar.
  • Os workflows são mantidos pequenos e os artefatos são enviados para poderem ser reutilizados em outros workflows. Porém, é necessário um token para baixar os artefatos.

• Conclusão

  • O tempo de merge caiu bastante com os novos scripts de CI, mas o processo de configuração é complexo e o debugging é difícil. É necessária inovação.

[GN⁺]

Opiniões do Hacker News

• Há quem diga que o GitLab é melhor, mas o GitLab também tem problemas de outro tipo

  • Depois de usar várias ferramentas de CI, o importante é escrever o máximo possível da lógica de CI no próprio código
  • Vale a pena investir para que o pipeline possa ser executado localmente na máquina do desenvolvedor
  • Evite YAML sempre que possível
  • Não dependa de ferramentas novas financiadas por capital de risco
  • Use runners próprios sempre que possível e opere on-premises

• É interessante como o GitHub Actions e o DevOps são amplamente criticados

  • Configurar e testar pode ser trabalhoso, mas quando funciona quase não precisa mexer
  • Tirando atualizações de versão do Node, quase não mexi no workflow em 4 anos
  • Pessoalmente, estou satisfeito

• Usei GitLab e depois mudei para o GitHub, mas fiquei decepcionado

  • O GitHub Actions parece muito inferior ao GitLab
  • Se eu fosse tocar uma empresa, escolheria o GitLab

• O pior é ter um loop de feedback de 30–60 segundos

  • Tentei reproduzir o ambiente do GHA localmente, mas foi impossível
  • Um erro pequeno acaba consumindo muito tempo

• Não quero que o CI modifique o código automaticamente

  • Verificações triviais deveriam rodar em um pre-commit hook

• É decepcionante que a evolução do GitHub Actions pareça ter parado

  • É uma pena que o desenvolvimento do Earthly e do Dagger tenha sido interrompido
  • Ao avaliar o Depot.dev, ficou claro que uma equipe muito competente resolveu bem esse problema

• O GitHub Actions incentiva o mau uso de contêineres como scripts de instalação

  • Muito tempo do workflow é gasto executando instaladores

• Escolher a ferramenta certa é importante

  • O GitHub Actions serve para tarefas simples, mas não para tarefas complexas

• Por causa dos problemas de segurança do GitHub Action, é preciso fixar dependências usando hashes

  • Usar hashes é muito mais seguro

• O GitHub Actions tem muitos problemas

  • Limite de cache de 10 GB, limite de concorrência por tipo de runner, custo alto etc.
  • O Depot.dev tenta tornar o GitHub Actions mais rápido e resolver esses problemas
  • Ele acelera a build de imagens Docker e otimiza os runners para tornar o trabalho muito mais rápido
  • O GitHub Actions é popular, mas ainda há muito espaço para melhorias