Git e GitHub Actions

A aba Deploy conecta um repositório Git ao serviço. A cada push na branch escolhida o site é reconstruído e publicado. Para fluxos próprios (build no GitHub, imagem Docker) existem tokens de deploy.

Conectar um repositório

1. Abra Deploy → Configurar.
2. Informe a URL do repositório e a branch.
3. Salve. O painel mostra uma deploy key (chave pública de leitura), uma URL de webhook e o segredo do webhook (exibido uma única vez; se perder, use *Gerar novo segredo*).
4. No GitHub, em *Settings → Deploy keys*, adicione a chave. Em *Settings → Webhooks*, cadastre a URL do webhook (conteúdo application/json), cole o segredo no campo *Secret* e marque só o evento de push.

Ao salvar de novo o mesmo repositório, a deploy key e o webhook continuam os mesmos: se já estão no GitHub, nada a refazer.

Publicar

• Automático: cada push na branch configurada dispara um deploy.
• Manual: o botão Publicar agora na aba Deploy.

O histórico lista cada deploy com o commit, a data e o estado. Abrindo um deploy você vê os logs de cada fase. Enquanto ele roda dá para Cancelar; em um deploy concluído você pode Reverter (rollback) para uma versão anterior que ainda esteja disponível.

Como o agente decide o build

O agente procura, nesta ordem: vixpi.json → Dockerfile → compose.yaml → Railpack → Nixpacks → templates. Para controlar o resultado, use o vixpi.json.

A troca de versão é feita por *blue-green*: a versão nova sobe ao lado, passa no healthcheck e só então recebe o tráfego. Se falhar, a antiga continua no ar.

Tokens de deploy

Um token autoriza apenas disparar deploys daquele serviço: não lê arquivos nem muda configuração.

1. Na aba Deploy → Configurar, crie um token e dê um nome (ex.: github-actions).
2. Copie o valor na hora. Ele só aparece uma vez; o painel guarda apenas o hash.
3. Para invalidar, use Revogar.

No repositório do GitHub, guarde o token como secret VIXPI_DEPLOY_TOKEN e a URL da API como variável VIXPI_API_URL.

Disparar por GitHub Actions

POST {VIXPI_API_URL}/v1/hosting/deploy com Authorization: Bearer <token>. A resposta é 202 com o deploymentId. Há duas formas:

• Pelo código: { "ref": "main" } — o serviço clona o repositório configurado.
• Por imagem: { "image": "ghcr.io/minha-org/meu-app:1.4.2" } — baixa a imagem e troca a versão, sem build. Precisa ser linux/amd64. O container roda sempre com o usuário da sua conta, independentemente do USER do Dockerfile.

Para registry privado, envie também registryAuth com username e password; a credencial é guardada cifrada e nunca aparece em log.

Exemplo de workflow que publica no GHCR e implanta:

name: deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

      - name: Implantar na Vixpi
        run: |
          curl -fsS -X POST "${{ vars.VIXPI_API_URL }}/v1/hosting/deploy" \
            -H "Authorization: Bearer ${{ secrets.VIXPI_DEPLOY_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d "$(jq -n --arg image "ghcr.io/${{ github.repository }}:${{ github.sha }}" \
                  --arg user "${{ github.actor }}" \
                  --arg pass "${{ secrets.GHCR_READ_TOKEN }}" \
                  '{image: $image, registryAuth: {username: $user, password: $pass}}')"

Se o pacote do GHCR for público, omita registryAuth. Para implantar pelo código em vez de imagem, troque o último passo por -d '{"ref":"main"}'.

Erros da chamada: 401 token ausente, inválido ou revogado; 400 imagem ou credencial inválida; 404 serviço não encontrado.