Dando ao Agente de Codificação do GitHub Copilot um Postgres Inicializado

Você atribui uma tarefa ao Copilot, e alguns minutos depois um pull request está aguardando revisão com suas verificações já em vermelho. As migrações foram executadas. O que quebrou foi tudo que está a jusante delas, os testes que esperavam que um cliente existisse, um pedido para se juntar, uma linha para afirmar, tudo disparando contra um esquema vazio. O seeding do banco de dados do agente de codificação do Copilot é a solução, e tudo se resume a um arquivo, .github/workflows/copilot-setup-steps.yml, que popula o Postgres antes que o agente escreva uma linha.

O GitHub renomeou o agente de codificação do Copilot para agente de nuvem do Copilot em 1º de abril de 2026, e ambos os nomes estão ativos em sua documentação agora, então vou me manter com "agente de codificação" ao longo do texto. Por que você entregaria a esse agente dados recém-gerados em vez de uma cópia da produção é um assunto à parte; aqui estou considerando essa decisão como tomada e conectando o ambiente.

Onde uma tarefa do agente de codificação realmente é executada

Cada tarefa que o Copilot assume é executada em um ambiente descartável do GitHub Actions provisionado para aquele único trabalho, em um único branch que se torna um único pull request. Nada persiste entre as tarefas. Quando a execução termina, o ambiente desaparece, então o banco de dados por trás dele precisa ser construído do zero a cada vez, em vez de ser assumido de uma sessão anterior. A fase de configuração que você controla tem um limite de 59 minutos, e, de outra forma, o ambiente se comporta como os trabalhos do Actions que você já escreve, até os mecanismos de contêiner de serviço, com uma reviravolta no modelo de segredos.

O arquivo copilot-setup-steps.yml, e a linha que o quebra silenciosamente

A configuração reside em .github/workflows/copilot-setup-steps.yml, e lê-se como um fluxo de trabalho comum, exceto que apenas um trabalho dentro dele é lido, o nomeado copilot-setup-steps. Nomeie-o de qualquer outra forma e o GitHub ignora o arquivo sem erro e sem aviso, e o agente começa contra um banco de dados vazio como se você nunca o tivesse escrito. A documentação de personalização do ambiente do GitHub lista as chaves honradas, e o conjunto é pequeno. Você obtém steps, permissions, runs-on, services, snapshot, e timeout-minutes, e qualquer coisa fora desse conjunto é silenciosamente descartada. snapshot é listado como honrado, mas a documentação não descreve o que faz, então vou deixá-lo no conjunto sem adivinhar seu comportamento.

O trabalho é executado antes que o agente comece, e também é acionado em workflow_dispatch e em qualquer push ou pull request que toque o próprio arquivo, o que permite que você prove que a configuração está verde sem esperar por uma tarefa real. Um requisito é fácil de perder. O arquivo precisa estar no seu branch padrão para ter efeito; uma cópia em um branch de recurso não faz nada.

Um arquivo de configuração que migra e faz o seeding do Postgres

Aqui está uma versão mínima e executável que levanta um serviço PostgreSQL, executa suas migrações contra ele e faz o seeding com o Seedfast.

name: Copilot setup steps

on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: app
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4

      - name: Executar migrações
        run: npm run migrate
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/app

      - name: Fazer o seeding com Seedfast
        run: npx seedfast seed --scope "20 customers with orders and line items" --output json
        env:
          DATABASE_URL: postgres://postgres:postgres@localhost:5432/app
          SEEDFAST_API_KEY: ${{ secrets.SEEDFAST_API_KEY }}

O bloco services levanta um contêiner postgres:16 com uma verificação de saúde que mantém a execução até que o banco de dados responda, o mesmo padrão que qualquer trabalho do Actions utiliza, então nada aqui é específico do Copilot até o segredo. As migrações são executadas primeiro contra localhost:5432, então a etapa de seeding chama npx seedfast seed (npx é enviado com npm) com um escopo em linguagem simples e --output json para um resultado legível por máquina. O Seedfast lê o esquema a partir daquela string de conexão e compõe novas linhas cujas relações se resolvem, inventando cada valor em vez de copiar qualquer coisa de um banco de dados real, a abordagem de gerar por execução por trás de dados sintéticos em CI/CD. Códigos de saída e o restante da mecânica do lado do pipeline vivem na documentação de seeding CI/CD.