Composite Actions vs Reusable Workflows

Composite Actions

Você já está utilizando composite actions para agrupar etapas como build, tag e push (CI), e login e sincronização com ArgoCD (CD). Essas ações compostas:

• Seguem o princípio DRY (Don’t Repeat Yourself) e facilitam a manutenção de etapas comuns (zup.com.br, DEV Community).
• São chamadas como um único step em um workflow e não expõem cada passo no log — eles aparecem como um bloco único (GitHub Docs, DEV Community).
• Não permitem múltiplos jobs — são executadas dentro de um job existente (GitHub Docs, zup.com.br).

Reusable Workflows

Outra alternativa poderosa é usar workflows reutilizáveis, que permitem definir um fluxo completo com múltiplos jobs:

• Cada job e step é logado individualmente — maior clareza e visibilidade (GitHub Docs, DEV Community).
• Podem conter múltiplos jobs, usar diferentes runners ou definirem estratégias como matrix (GitHub Docs, zup.com.br).
• Chamados diretamente dentro de um job com uses: org/repo/.github/workflows/…@vX, e aceitam inputs, outputs e até secrets (GitHub Docs, incredibuild, The GitHub Blog).
• Podem ser mais fáceis de versionar e auditáveis, principalmente quando mantidos em repositório centralizado (Best Practices for Multi-Project CI/CD, wellarchitected.github.com).

Melhores Práticas Recomendadas

1. Modularização com Propósito

• Composite Actions são ideais para tarefas repetitivas e bem definidas, como build/push de Docker ou deploy com ArgoCD.
• Use Reusable Workflows quando precisar orquestrar múltiplos jobs (por exemplo: build → testes → deploy).

2. Repositório Dedicado e Estrutura Recomendada

• Crie repositórios separados para suas actions e workflows reutilizáveis. Isso permite versionamento claro, controle de acesso e governança de ciclo de vida (Best Practices for Multi-Project CI/CD).
• Se mantiver dentro do mesmo repositório (menos ideal), organize composite actions em .github/actions/... e workflows reutilizáveis em .github/workflows/... (DEV Community, Best Practices for Multi-Project CI/CD).

3. Versionamento

• Use tags semânticas (semver): v1.0.0, v1.1.0, etc., para melhor rastreabilidade (incredibuild, Earthly).
• Na chamada do workflow ou action, referencie a tag (ou SHA imutável) para evitar quebras não esperadas.

4. Inputs, Outputs e Parameterização

• Defina parâmetros claros nos seus workflows (environment, app_name, etc.) e use outputs para compartilhar informações entre jobs (incredibuild, Earthly).
• Isso facilita personalização e manutenção centralizada.

5. Logging e Debug

• Prefira reusable workflows quando precisar de visibilidade detalhada sobre o que está acontecendo.
• Em composite actions, inclua logs e mensagens significativas, especialmente em casos de erro.

6. Documentação

• Documente cada action e workflow: o que faz, quais inputs requer, quais outputs produz, exemplos de uso (Earthly).
• Isso facilita a adoção por outros times e a manutenção futura.

7. Centralização e Governança

• Se você gerencia múltiplos projetos, considere montar uma organização ou repo centralizado (um “marketplace interno”) com guidelines, naming conventions, contribuições e revisões estruturadas (wellarchitected.github.com).
• Nomeação padronizada ajuda na descoberta (ci-build, cd-deploy-argocd, etc.) (wellarchitected.github.com, The GitHub Blog).

8. Testes

• Crie workflows de teste que acionem seus workflows reutilizáveis com diferentes inputs (usando strategy: matrix) para garantir estabilidade (Earthly).

Recomendação Aplicada ao seu Caso

Conclusão

Seu modelo atual — com CI e CD em composite actions — é funcional e modular. Para ir além:

• Use reusable workflows quando quiser orquestrar múltiplos jobs ou precisar de logs mais ricos.
• Mantenha actions e workflows em repositórios separados, com versionamento semântico e documentação clara.
• Invista em centralização, governança e testes automatizados.