Pular para o conteúdo

GitHub Actions em profundidade

Intermediário26 min de leituracicd

Um workflow contém jobs; cada job executa steps em um runner novo. Dados não passam entre jobs por acaso: use artefatos, outputs ou registry. Mantenha permissões declaradas e ações de terceiros fixadas por commit SHA, não por tag mutável.

name: validar
on: [pull_request]
permissions: { contents: read }
concurrency:
group: pr-${{ github.ref }}
cancel-in-progress: true
jobs:
teste:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@SUBSTITUA_POR_SHA
- uses: actions/setup-node@SUBSTITUA_POR_SHA
with: { node-version: 22, cache: npm }
- run: npm ci && npm test

concurrency evita gastar recursos em commits obsoletos. Em uma matriz, publique apenas em um job controlador; jobs paralelos não devem disputar a mesma tag. Cache de dependência usa chave do lockfile e é uma otimização, jamais fronteira de confiança.

Para OIDC, dê id-token: write somente ao job de deploy e configure no provedor uma relação que aceite repositório, branch/ambiente e workflow específicos. Não exponha segredos de cloud a PRs de forks. Use environment: production para proteções e aprovação.

Runners self-hosted são parte da superfície de produção: código não confiável pode deixar processo ou credencial no host. Separe-os por confiança, elimine-os após uso quando possível e não monte socket Docker em job de PR.

Próximo passo: aplique gates e rollback em Estratégias de deploy.