Rodando GitHub Actions na raça (sem push)

“Dá pra rodar a action sem fazer push? Tipo… direto do terminal?” Essa foi a pergunta que me acendeu uma luz. Era um dia comum, mais um deploy de rotina, e lá estava eu empilhando commits desnecessários no Git só pra testar uma mudança no workflow. Aquela sensação de que devia ter um jeito melhor, mais rápido, mais limpo. E adivinha? Tinha mesmo. Foi assim que comecei a explorar um mundo novo com o gh — o CLI oficial do GitHub. Neste artigo, vou te mostrar como essa simples ferramenta me salvou tempo, organizou meus fluxos de trabalho e ainda deu aquele ar de maturidade no CI/CD da equipe. Se você curte dominar suas ferramentas, vem comigo. Conhecendo o gh – o CLI oficial do GitHub Se você nunca usou o gh, para tudo e instala agora: brew install gh # macOS sudo apt install gh # Debian/Ubuntu choco install gh # Windows Esse é o GitHub no terminal, com comandos pra tudo: PR, issue, release, clone e o que nos interessa aqui: executar workflows de forma manual. Rodando um workflow direto do terminal Suponha que você tem um workflow chamado deploy-staging.yml dentro da pasta .github/workflows/. Você pode rodar ele com o seguinte comando: gh workflow run deploy-staging.yml --ref main Simples assim. O --ref main diz que ele deve usar o conteúdo atual da branch main como base. E se meu workflow tiver inputs? Melhor ainda. Você pode passar os inputs diretamente via --field, igualzinho um formulário: gh workflow run deploy-staging.yml \ --ref main \ --field environment=staging \ --field ecr-repository=tz-staging-ecr Isso é perfeito pra pipelines que precisam de decisões contextuais (tipo staging vs prod) ou que usam inputs customizados no YAML. Rodar actions localmente com act Se você é do tipo que quer ver tudo rodando no seu terminal, tem uma ferramenta chamada act que roda suas workflows localmente, como se fosse o GitHub. brew install act act -j deploy-staging O -j vem de "job". E sim, ele lê seu .github/workflows/deploy-staging.yml normalmente. Só se liga que alguns actions podem precisar de adaptação pra funcionar localmente — principalmente quando o workflow usa segredos da organização ou do repositório, como credenciais da AWS, tokens de API ou secrets personalizados. Exemplo com variáveis de ambiente locais (simulando secrets) Se seu workflow usa algo assim: env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} Você pode simular esses secrets criando um arquivo .secrets com: AWS_ACCESS_KEY_ID=AKIA...EXEMPLO AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXEMPLO E depois rodar o act assim: act -j deploy-staging --secret-file .secrets Ou definir direto com --env: act -j deploy-staging \ --env AWS_ACCESS_KEY_ID=... \ --env AWS_SECRET_ACCESS_KEY=... Dessa forma, você consegue simular a execução completa sem precisar fazer push e sem depender dos secrets reais do GitHub. Dica de ouro Transforme seus fluxos de deploy em um comando simples com Makefile ou npm run. Exemplo com Makefile: deploy-staging: gh workflow run deploy-staging.yml --ref main --field environment=staging Agora basta rodar: make deploy-staging Conclusão Esse pequeno ajuste no seu fluxo pode economizar horas de git push, evitar commits desnecessários, e deixar seu time com uma ferramenta poderosa nas mãos. Comece a rodar seus workflows com controle total — sem sujar o histórico, sem gerar PR à toa, e sem perder tempo. No fim do dia, é sobre isso: dominar a ferramenta que você já usa. O gh é só a porta de entrada. Curtiu esse conteúdo? Me segue aqui no Medium, compartilha com quem precisa desse empurrão e bora evoluir junto.

Mar 28, 2025 - 02:59

Rodando GitHub Actions na raça (sem push)

“Dá pra rodar a action sem fazer push? Tipo… direto do terminal?”

Essa foi a pergunta que me acendeu uma luz. Era um dia comum, mais um deploy de rotina, e lá estava eu empilhando commits desnecessários no Git só pra testar uma mudança no workflow.

Aquela sensação de que devia ter um jeito melhor, mais rápido, mais limpo. E adivinha? Tinha mesmo.

Foi assim que comecei a explorar um mundo novo com o gh — o CLI oficial do GitHub. Neste artigo, vou te mostrar como essa simples ferramenta me salvou tempo, organizou meus fluxos de trabalho e ainda deu aquele ar de maturidade no CI/CD da equipe.

Se você curte dominar suas ferramentas, vem comigo.

Conhecendo o `gh` – o CLI oficial do GitHub

Se você nunca usou o gh, para tudo e instala agora:

brew install gh        # macOS
sudo apt install gh    # Debian/Ubuntu
choco install gh       # Windows

Esse é o GitHub no terminal, com comandos pra tudo: PR, issue, release, clone e o que nos interessa aqui: executar workflows de forma manual.

Rodando um workflow direto do terminal

Suponha que você tem um workflow chamado deploy-staging.yml dentro da pasta .github/workflows/.

Você pode rodar ele com o seguinte comando:

gh workflow run deploy-staging.yml --ref main

Simples assim.

O --ref main diz que ele deve usar o conteúdo atual da branch main como base.

E se meu workflow tiver inputs?

Melhor ainda. Você pode passar os inputs diretamente via --field, igualzinho um formulário:

gh workflow run deploy-staging.yml \
  --ref main \
  --field environment=staging \
  --field ecr-repository=tz-staging-ecr

Isso é perfeito pra pipelines que precisam de decisões contextuais (tipo staging vs prod) ou que usam inputs customizados no YAML.

Rodar actions localmente com `act`

Se você é do tipo que quer ver tudo rodando no seu terminal, tem uma ferramenta chamada act que roda suas workflows localmente, como se fosse o GitHub.

brew install act
act -j deploy-staging

O -j vem de "job". E sim, ele lê seu .github/workflows/deploy-staging.yml normalmente.

Só se liga que alguns actions podem precisar de adaptação pra funcionar localmente — principalmente quando o workflow usa segredos da organização ou do repositório, como credenciais da AWS, tokens de API ou secrets personalizados.

Exemplo com variáveis de ambiente locais (simulando secrets)

Se seu workflow usa algo assim:

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Você pode simular esses secrets criando um arquivo .secrets com:

AWS_ACCESS_KEY_ID=AKIA...EXEMPLO
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXEMPLO

E depois rodar o act assim:

act -j deploy-staging --secret-file .secrets

Ou definir direto com --env:

act -j deploy-staging \
  --env AWS_ACCESS_KEY_ID=... \
  --env AWS_SECRET_ACCESS_KEY=...

Dessa forma, você consegue simular a execução completa sem precisar fazer push e sem depender dos secrets reais do GitHub.

Dica de ouro

Transforme seus fluxos de deploy em um comando simples com Makefile ou npm run.

Exemplo com Makefile:

deploy-staging:
    gh workflow run deploy-staging.yml --ref main --field environment=staging

Agora basta rodar:

make deploy-staging

Conclusão

Esse pequeno ajuste no seu fluxo pode economizar horas de git push, evitar commits desnecessários, e deixar seu time com uma ferramenta poderosa nas mãos.

Comece a rodar seus workflows com controle total — sem sujar o histórico, sem gerar PR à toa, e sem perder tempo.

No fim do dia, é sobre isso: dominar a ferramenta que você já usa. O gh é só a porta de entrada.

Curtiu esse conteúdo? Me segue aqui no Medium, compartilha com quem precisa desse empurrão e bora evoluir junto.