GitHub Actions e Hangar: teste o pull request, publique após o merge

GitHub Actions pode verificar seu código antes de ele entrar na branch de produção. O Hangar pode iniciar um build e um deploy quando recebe um push nessa branch. São duas etapas distintas: um workflow verde não confirma que a aplicação foi publicada.

Neste fluxo, a aprovação dos testes acontece antes do merge, por uma regra do GitHub. Não há dependência nativa de “aguardar CI” assumida no deploy automático do Hangar.

Acrescente um teste que faça uma requisição real

Use os arquivos app.mjs, server.mjs e package.json do tutorial da API Node.js. Crie app.test.mjs:

import assert from "node:assert/strict";
import test from "node:test";
import { createApp } from "./app.mjs";

test("API responde ao health check e a uma rota inexistente", async () => {
  const server = createApp();
  await new Promise((resolve, reject) => {
    server.once("error", reject);
    server.listen(0, "127.0.0.1", resolve);
  });

  try {
    const base = `http://127.0.0.1:${server.address().port}`;
    const health = await fetch(`${base}/health`);
    assert.equal(health.status, 200);
    assert.deepEqual(await health.json(), { status: "ok" });

    const missing = await fetch(`${base}/inexistente`);
    assert.equal(missing.status, 404);
    assert.deepEqual(await missing.json(), { error: "not_found" });
  } finally {
    await new Promise((resolve, reject) => {
      server.close((error) => (error ? reject(error) : resolve()));
    });
  }
});

Execute npm run check e npm test. O teste abre uma porta local disponível, verifica duas respostas HTTP e fecha o servidor. A porta zero é útil aqui para o teste; a configuração de produção do tutorial usa uma porta definida.

Crie o workflow de CI

Versione o package-lock.json e salve este arquivo como .github/workflows/ci.yml:

name: CI

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  verify:
    name: Verificar API
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: actions/setup-node@v7
        with:
          node-version: "24"
          cache: npm
      - run: npm ci
      - run: npm run check
      - run: npm test

As versões acima foram conferidas nos repositórios oficiais de checkout e setup-node em 14 de setembro de 2026. Para a API do exemplo não existe build. Em uma aplicação compilada, acrescente o comando real de build e os testes apropriados.

Torne o teste uma condição do merge

Abra um pull request e confirme que o job “Verificar API” aparece e passa. Nas regras da branch main, exija pull request e esse status check antes do merge. Revise também quem pode ignorar a regra ou enviar pushes diretamente. A disponibilidade e as opções dependem do repositório e do plano GitHub; consulte a documentação de branches protegidas.

Se você usar fila de merge, adapte os eventos e checks ao fluxo da fila antes de adotá-la. O exemplo acima cobre pull requests e pushes comuns.

Configure o deploy no Hangar

No serviço, selecione o repositório, a branch main, a origem do build e o comando de início. Ative deploy automático por push quando estiver pronto para publicar alterações dessa branch.

O caminho passa a ser: abrir PR → executar CI → cumprir as regras de merge → fazer merge → acompanhar o deploy no Hangar. O job de CI que roda novamente no push não bloqueia, por si só, o webhook da plataforma. Se sua operação precisa de aprovação adicional após o merge, mantenha o deploy automático desativado e publique manualmente pelo painel após essa aprovação.

Não é necessário incluir credenciais de produção no workflow deste exemplo. As variáveis da aplicação ficam na configuração do serviço. Também não há chamada a endpoint de deploy nem token público presumido do Hangar.

Verifique a publicação no lugar certo

Confirme no Hangar a versão publicada, o estado do deploy e os logs. Depois acesse /health e teste uma operação relevante da aplicação. Uma notificação do GitHub deve dizer “CI aprovado”; só anuncie “deploy concluído” depois de verificar o resultado da publicação.

Para homologação, crie um ambiente e um serviço com a branch e as variáveis adequadas. Esse é um ambiente configurado por você, não um preview automático criado e removido a cada PR. Veja como organizar o primeiro projeto antes de ampliar o fluxo.