Padrões de Workflow do GitHub Actions

Quando Usar

Implemente testes, builds de matriz, preparação de artefatos ou um workflow de implantação explicitamente autorizado para um repositório existente.

Entradas

Inspecione os scripts reais do repositório, o arquivo de lock, os runtimes suportados, os nomes de verificação necessários e a política de lançamento. Leia resources/implementation-playbook.md e references/common-workflows.md antes de escolher os limites das jobs.

Workflow de Teste

Este exemplo Node assume que o repositório de destino declara npm test e suporta Node 22. Adapte o runtime e o comando ao projeto real. As revisões de action fixadas são entradas de revisão explícitas; verifique-as antes de adotar ou atualizar o template.

name: Test
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd
        with:
          persist-credentials: false
      - uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444
        with:
          node-version: '22'
          cache: npm
      - run: npm ci
      - run: npm test

Builds de Matriz

Adicione uma matriz apenas para as versões e sistemas operacionais que o projeto suporta. Mantenha as dependências reproduzíveis, identifique combinações com falha e evite ocultar falhas com continue-on-error genérico. Teste o comportamento de required-check quando as jobs são puladas condicionalmente.

Build e Publicação

Construa um artefato a partir do commit testado e registre sua identidade. A publicação requer uma job confiável separada com a permissão mínima de registro. Não publique artefatos produzidos por código arbitrário não confiável em um contexto privilegiado; vincule artefatos aceitos à sua origem exata e ao workflow que os produziu.

Implantação

Use o caminho de lançamento protegido do projeto. Identifique o artefato imutável, o destino, a identidade da carga de trabalho, as verificações de rollout e rollback antes de adicionar os comandos de implantação. Um ambiente GitHub nomeado não configura revisores automaticamente. Verifique suas proteções reais. Não rotule um comando echo de placeholder como uma implantação bem-sucedida.

Verificação

Execute uma alteração que passa e uma falha de teste deliberada em um branch de tópico. Confirme que a verificação com falha impede a publicação downstream. Inspecione tokens, isolamento de runner, caches e limites de artefatos. Mantenha credenciais de produção ausentes de jobs de validação não confiáveis.

Exemplo

Um projeto precisa de testes Linux e Windows. Selecione seu runtime suportado, adicione as duas combinações de runner e confirme que qualquer falha bloqueia o resultado necessário. Prepare a publicação separadamente; não adicione credenciais de registro à matriz.

Limitações

Esta habilidade fornece padrões, não um programa de implantação instalado. A política do repositório, a confiança do runner e as configurações de ambiente devem ser inspecionadas. Revise cada action de terceiros em seu SHA de commit completo e trate logs e artefatos carregados como possíveis caminhos de exposição de dados.

Fontes

• Orientação de workflow seguro do GitHub