Vou pensar duas vezes antes de usar GitHub Actions de novo

• Insatisfações com o GitHub Actions
  • A equipe é composta por cerca de 15 engenheiros, e todos fazem push contínuo de código na branch main
  • O código existe em formato de monorepo, dividido em vários módulos, e é implantado várias vezes ao dia por meio de desenvolvimento baseado em trunk
• Há casos em que o GitHub Actions funciona bem, mas, em determinadas escalas ou ambientes, suas limitações ficam bem claras

Pull requests e verificações obrigatórias

• O monorepo é dividido em várias pastas, e cada pasta executa testes, build e deploy de forma independente
• Usa-se o recurso paths do GitHub Actions para disparar o pipeline correspondente apenas quando há mudanças em uma pasta específica
• Exigir que todas as verificações passem antes de mesclar um pull request é um bom princípio, mas isso causa problemas quando combinado com uma estrutura de monorepo
  • Exemplo: a verificação web-app1 - Unit tests foi definida como “obrigatória”, mas, se não houver mudanças na pasta web-app1, essa verificação não é executada
  • Como resultado, mesmo que apenas uma pasta tenha sido alterada, os testes relacionados a outras pastas não são executados, e isso acaba impedindo a própria mesclagem
• Isso poderia ser resolvido se o GitHub tratasse isso não pelo nome das verificações obrigatórias, mas com algo como “a mesclagem é permitida se todas as verificações acionadas no momento forem aprovadas”, mas é lamentável que nada tenha mudado em 3 anos
• As threads de issues relacionadas no GitHub, 1, 2, também mostram o grande impacto desse problema
• No fim, contornar isso exige executar pipelines adicionais ou mantê-los, o que é complexo e caro

Reutilização e YAML

• À medida que o pipeline cresce, fica cada vez mais difícil gerenciá-lo com GitHub Actions
  • Acabam surgindo muitos if, e, mesmo separando os workflows, o número de arquivos a administrar aumenta, prejudicando a manutenção
• Mesmo nos casos de reutilização em que a chamada deveria terminar em uma única linha, são necessárias várias linhas e configurações duplicadas, a ponto de já haver mais de 30 arquivos acumulados na pasta .github
• A cláusula needs também pode atrasar a descoberta de erros quando, numa refatoração, não reflete jobs removidos
• Como não é possível executar GitHub Actions localmente, desenvolvimento e testes ficam complicados
  • Existem ferramentas como act, mas, na prática, muitas vezes elas têm tantas limitações que não correspondem às expectativas

Falta de atenção do GitHub

• Entre os problemas acima, o maior é que o GitHub parece não considerar essas questões muito importantes
• Como várias issues estão abertas há anos e não foram incluídas no roadmap público, não parece haver muita intenção de melhorar
• Houve reação da comunidade quando, recentemente, várias issues sobre problemas discutidos há muito tempo foram fechadas em massa

Opções

• Considerando esses problemas e a aparente falta de disposição do GitHub para melhorá-los, é preciso pensar com cuidado antes de adotar GitHub Actions
• O mercado oferece várias outras opções de CI/CD, como GitLab, Jenkins e TeamCity
• Também vale a pena avaliar ferramentas que propõem abordagens novas, como o Dagger

[bichi]

CI/CD: GitLab é o melhor

[devsepnine]

Eu também me lembro de, depois de usar GitLab, quando fui colocado em um ambiente com GitHub Actions, pensar que nada funcionava...

[jjpark78]

Uma das minhas maiores insatisfações também é o fato de não dar para gerenciar repositórios no GitHub agrupando-os por categorias.

[jjpark78]

Acho que, para pipelines, o GitLab é realmente muito bom. Tudo isso que foi dito acima o GitLab faz.
No caso de um monorepo, é bem prático configurar que, quando determinada pasta for alterada, certas coisas devam ser executadas para os testes.

[tujuc]

Isso meio que exige conhecer a história do GitHub Actions...

As primeiras versões do GitHub Actions tinham uma cara bem diferente da situação de hoje... Antes de abrir, uns 6 meses antes (minha memória está meio falha), o GitHub foi adquirido pela Microsoft, e acho que o desenvolvimento do Actions passou a ser feito junto com a equipe do Azure DevOps na Microsoft. Nessa época, pararam de surgir novos recursos no Azure DevOps, e os recursos que estavam lá começaram a aparecer como novidades no GitHub Actions... Foi nessa fase que mudou para YAML e o ambiente atual acabou sendo formado... snif snif

Depois disso, parece que os desenvolvedores voltaram para suas áreas e o produto acabou ficando sem receber muitos ajustes... É uma pena... Na empresa em que estou hoje, montamos o CI/CD com base no GitHub Actions... por enquanto não sentimos falta de nada, então continuamos usando...

Acho que vamos ter que ficar de olho mesmo...

[GN⁺]

Comentários do Hacker News

• A DSL do pipeline não deve incluir a lógica real; deve ser usada apenas para orquestrar tarefas. Trabalhos complexos devem ser transformados em scripts para que possam ser executados de forma simples. Assim, é possível realizar as mesmas tarefas com facilidade no GitHub Actions, Jenkins, Azure DevOps etc.

• Ao configurar o GitHub Actions, é melhor evitar actions prontas e usá-lo apenas como um executor simples de shell. Escreva scripts em Python, Ruby, Bash etc. e execute-os no GitHub Action; isso facilita os testes locais e reduz sofrimento desnecessário.

• O GitHub Actions pode executar verificações apenas quando certas condições são atendidas. Mas, ao usar essas regras, você acaba esbarrando no problema de "Pull request e verificações obrigatórias". Ao usar serviços externos, as verificações obrigatórias precisam passar sem falta; caso contrário, não é possível fazer o merge.

• Como forma de resolver o problema de "Pull request e verificações obrigatórias", é possível criar uma versão "no op" de cada workflow de verificação obrigatória para executá-la quando as condições não forem atendidas e encerrar com código 0. É uma funcionalidade básica, mas uma solução um tanto complicada.

• O Travis CI era excelente para testar CI localmente. O GitHub Actions foi criado para competir com o GitLab CI, enquanto o GitHub vinha perdendo participação no mercado corporativo.

• Recomendo experimentar o Buildkite. Se você quiser ir além do GitHub Actions, o Buildkite pode ser uma boa alternativa. Já o usei em grandes empresas de tecnologia dos EUA, e foi a única parte agradável de CI.

• A arquitetura do GitHub Actions pode levar a decisões de segurança equivocadas. Por exemplo, segredos da organização ou do repositório são convenientes, mas podem se tornar uma vulnerabilidade. Ambientes de repositório podem ter segredos separados, mas é preciso garantir que apenas o workflow correto tenha acesso ao ambiente correto.

• A filosofia geral dos sistemas de CI está errada. Em vez de o CI executar o código, o código deveria executar o CI. O CI deveria fornecer uma API para que os usuários possam enviar informações ao sistema.

• É possível usar Bazel para fazer a ferramenta de CI compilar targets do Bazel e, quando necessário, aumentar o paralelismo por meio de execução remota de builds. Isso é adequado para bases com cerca de 10M+ linhas de código ou serviços de grande porte.

• No GitHub, é possível definir "verificações obrigatórias", que devem estar sempre verdes. Porém, como elas só executam quando há mudanças em pastas específicas, não é possível fazer merge quando as mudanças estão em outras pastas. Se você não executa todos os testes, a integração perde o sentido; por isso, é preciso fazer os testes rodarem rapidamente.