Implantação via GitHub

Use Repositório GitHub como origem do projeto quando quiser publicar a aplicação a partir do código-fonte e do fluxo de build configurado na criação.

Pré-requisito

Antes de selecionar um repositório, faça estas duas etapas obrigatórias:

conecte sua conta GitHub à Zenifra
instale o GitHub App Zenifra

Guia detalhado:

Como conectar sua conta GitHub à Zenifra

Nota: O GitHub App pode ser instalado em conta pessoal ou organização. Em organizações, a instalação pode depender de aprovação administrativa.

Passos

No console, clique em Criar Projeto.
Em Origem de Projeto, escolha Repositório GitHub.
Selecione o repositório, a branch, o runtime e os comandos necessários.
Escolha se deseja habilitar auto-deploy.
Clique em Criar Projeto.

Comandos do projeto

Em projetos GitHub, a Zenifra executa a instalação padrão do runtime e depois roda apenas os comandos configurados no projeto.

pre-build é opcional
build é opcional
start é obrigatório

Isso significa que alguns projetos precisam apenas de start, enquanto outros também usam pre-build e build.

Auto-deploy

Quando auto-deploy estiver habilitado na criação do projeto, cada push na branch selecionada dispara uma nova atualização automaticamente.

Quando auto-deploy estiver desabilitado, o projeto não será atualizado automaticamente por push.

Use Ambientes de Preview para dar a cada pull request uma URL temporária sem substituir o projeto principal. Primeiro habilite a funcionalidade na aba Previews do projeto e guarde a API Key em um secret do GitHub.

O workflow recomendado usa os eventos opened, synchronize, reopened e closed. Com PREVIEW_ACTION=auto, a Action faz upsert nos três primeiros eventos e remove o preview quando o pull request é fechado. O mesmo pull request reutiliza a chave automática pr-<number>.

name: Preview Zenifra

on:
  pull_request:
    types: [opened, synchronize, reopened, closed]

permissions:
  contents: read

jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - name: Criar ou remover preview
        uses: zenifra/action-zenifra-deploy@v1
        with:
          PROJECT_ID: ${{ vars.ZENIFRA_PROJECT_ID }}
          API_KEY: ${{ secrets.ZENIFRA_API_KEY }}
          IMAGE: ${{ vars.ZENIFRA_PREVIEW_IMAGE }}
          PREVIEW: true
          PREVIEW_ACTION: auto
          PREVIEW_TTL: 24h
          WAIT_TIMEOUT: 10m

Para uma execução fora de pull request, use workflow_dispatch e informe uma PREVIEW_KEY estável:

on:
  workflow_dispatch:
    inputs:
      preview_key:
        description: Chave do Ambiente de Preview
        required: true
        type: string
      action:
        description: Operação
        required: true
        default: upsert
        type: choice
        options: [upsert, delete]

jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: zenifra/action-zenifra-deploy@v1
        with:
          PROJECT_ID: ${{ vars.ZENIFRA_PROJECT_ID }}
          API_KEY: ${{ secrets.ZENIFRA_API_KEY }}
          IMAGE: ${{ vars.ZENIFRA_PREVIEW_IMAGE }}
          PREVIEW: true
          PREVIEW_KEY: ${{ inputs.preview_key }}
          PREVIEW_ACTION: ${{ inputs.action }}

Fora de pull request, a chave é obrigatória. Um preview tem cobrança horária em BRL, TTL padrão de 24 horas e faixa de 1 a 168 horas. As variáveis do usuário sempre são copiadas dentro da plataforma, mas podem apontar para os mesmos serviços do projeto principal. O storage começa vazio e isolado; dados, domínios personalizados e comandos customizados de imagem não são herdados.

A Action aguarda a disponibilidade por polling limitado e fornece preview_id, preview_url, expires_at, operation_id e preview_status. Ela nunca publica API Keys ou valores de variáveis no Job Summary ou nos logs.

O que fica fixo depois da criação

Em projetos com origem GitHub, estes campos ficam definidos na criação e não ficam disponíveis para edição depois:

origem do projeto
branch
runtime
versão do runtime
auto-deploy

Depois da criação, os ajustes confirmados para projetos GitHub se concentram nos comandos pre-build, build e start.

Logs de Build

Depois que o projeto é criado, acompanhe cada publicação pela aba Logs de Build dentro da página do projeto no console.

Esse histórico mostra:

lista de builds recentes
status de cada build
saída detalhada de instalação de dependências
saída de pre-build, quando existir
saída de build, quando existir

Os logs públicos de build são filtrados para priorizar a saída útil do projeto.

O modal de logs atualiza em tempo real enquanto a build está em execução.

Retenção do histórico

O histórico de builds GitHub é retido por até:

30 builds por projeto
30 dias de idade

O que vencer primeiro define a remoção dos registros mais antigos.

URL

Todos os planos recebem uma URL da Zenifra em *.clients.zenifra.com. Em planos mais altos, o nome desse subdomínio pode ser personalizável.