Ir para o conteúdo

CI para os seus repositórios do GitHub
em servidores que nós mesmos operamos.

Cada push e pull request roda seus testes em uma sandbox em hardware do Enzonic que já está ligada quando o job chega, com logs ao vivo e um check no GitHub. Escreva um .enzonic/ci.yml curto ou mantenha os fluxos de trabalho do GitHub Actions que você já tem.

3.000 minutos por mês grátis. Sem cartão.

Ver uma configuração
$ git push origin maina41c9e2Execução #128 aprovada em 2m 18slint22stest (node 20)1m 08stest (node 22)1m 21sdeploy26spostgres:17 · healthyTodos os checks foram aprovados4 jobs · Enzonic CI
Minutos de CI por mês
jobs por vez
por job
de cache de dependências

Tudo que um pipeline precisa, sem nada para vigiar

Runners, serviços, caches e logs fazem parte do produto. Você escreve os passos.

Sandboxes que já estão em execução

Cada job recebe sua própria sandbox em hardware operado pelo Enzonic, inicializada com antecedência e descongelada quando o job chega.

Jobs de matrix e needs

Teste no Node 20 e no 22 ao mesmo tempo e faça deploy somente quando todas as células tiverem passado. Os jobs aguardam os jobs de que precisam.

Serviços Postgres e Valkey

Inicie um banco de dados real junto aos seus testes com uma linha, com verificação de saúde antes do primeiro passo.

Caches

Mantenha node_modules, wheels do pip ou a saída do build entre execuções, com uma key gerada a partir do seu lockfile.

Artefatos

Mantenha relatórios de cobertura, builds e capturas de tela, passe-os para os jobs seguintes e baixe-os por dias.

Logs ao vivo

Acompanhe cada passo enquanto ele roda, com cores, agrupado por passo, e os passos com falha abertos para você.

Checks no GitHub

Cada job informa um check com anotações na pull request, pronto para a proteção de branch.

Seus fluxos de trabalho, sem alterações

Grande parte dos fluxos de trabalho do GitHub Actions roda como está: matrix, services, containers e as ações de configuração comuns.

Agendamentos

Testes noturnos ou verificações semanais de dependências com uma linha cron, em UTC.

A Enzica corrige execuções com falha

Um clique em um job com falha: a Enzica encontra a causa, faz push de uma branch de correção e roda o pipeline nela.

A espera acabou, então a execução são os seus passos

A maior parte do tempo do CI vai para iniciar uma máquina, clonar o repositório e baixar dependências. O Enzonic CI faz esse trabalho antes de o seu job chegar.

  1. 01

    Sandboxes descongeladas, não inicializadas

    Um conjunto de sandboxes é inicializado com antecedência. Quando um job chega, uma é descongelada e entregue a ele, então não há máquina para iniciar.

  2. 02

    Checkouts a partir de um espelho local

    Cada runner mantém um espelho do seu repositório e busca apenas o que mudou, em vez de clonar do GitHub a cada job.

  3. 03

    Caches vinculados ao disco local

    Os caches de dependências ficam no runner e são vinculados ao job, em vez de baixados e descompactados antes.

Cada job mostra para onde foi o seu tempo: fila, sandbox, checkout, dependências, services, cache e passos.

Um arquivo no seu repositório

Faça commit de .enzonic/ci.yml e dê push. Os jobs rodam na ordem definida por needs, as células de matrix em paralelo, cada uma com seus próprios services, cache e artefatos.

  • o lint roda primeiro; ambas as células de teste começam quando ele passa
  • cada célula de teste tem seu próprio Postgres em localhost e como postgres:5432
  • os downloads do npm vêm do cache indexado por package-lock.json
  • a cobertura é mantida mesmo quando os testes falham
  • o deploy roda somente na main, com um segredo que os logs nunca mostram
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  lint:
    image: node:22
    steps:
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint
    image: node:${{ matrix.node }}
    matrix:
      node: [20, 22]
    services:
      postgres:
        image: postgres:17-alpine
        env: { POSTGRES_PASSWORD: postgres }
    env:
      DATABASE_URL: postgres://postgres:postgres@postgres:5432/postgres
    cache:
      key: npm-${{ hashFiles('package-lock.json') }}
      paths: [~/.npm]
    steps:
      - run: npm ci
      - run: npm test
    artifacts:
      - name: coverage-node${{ matrix.node }}
        paths: [coverage/]
        when: always

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    steps:
      - run: npx enzonic deploy --prod
        env:
          ENZONIC_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Já usa o GitHub Actions?

Conecte o repositório e seus .github/workflows rodam aqui sem edições, desde que usem o que está listado abaixo. Qualquer outra coisa é recusada com uma mensagem clara, nunca ignorada em silêncio.

Roda como está

  • actions/checkoutO commit da execução sempre é feito checkout
  • actions/setup-node, setup-python, setup-go, setup-javaEscolha a imagem do job; cache: adiciona o cache do gerenciador de pacotes
  • oven-sh/setup-bun, pnpm/action-setupImagem do Bun, com pnpm instalado
  • actions/cache (and /restore, /save)Um cache de job, restaurado primeiro e salvo no fim
  • actions/upload-artifact, download-artifactArtefatos mantidos com a execução e passados entre jobs
  • strategy.matrix, needs, if, services, containerIncluindo include / exclude e fail-fast

Não suportado

  • Outros usos: actions, actions Docker, actions compostas e fluxos de trabalho reutilizáveis
  • Saídas de passos e jobs (steps.*.outputs, needs.*.outputs)
  • Runners Windows e macOS
  • pull_request_target
A lista completa de compatibilidade

Preços

O CI vem com o seu plano do Enzonic Cloud, o mesmo que inclui Deploy e Databases. Comece no Free; faça upgrade quando precisar de mais minutos ou runners maiores. Apenas runners Linux.

Planos do Enzonic CI
Todos os planos do Cloud incluem CI
Free
US$ 0
Starter
US$ 5 / mês
US$ 4,17 por mês, cobrado anualmente
Recomendado
Pro
US$ 10 / mês
US$ 8,33 por mês, cobrado anualmente
Growth
US$ 19 / mês
US$ 15,83 por mês, cobrado anualmente
Business
US$ 29 / mês
US$ 24,17 por mês, cobrado anualmente
Minutos de CI por mês3.0005.0006.00015.00060.000
Jobs simultâneos2461020
Job mais longo360 min360 min360 min480 min720 min
Cache de dependências2 GB5 GB10 GB20 GB50 GB
Artefatos mantidos90 dias90 dias90 dias180 dias400 dias
Logs mantidos14 dias30 dias30 dias60 dias90 dias

Concessões para quem constrói

Você cria projetos open source, estuda, ensina ou toca uma organização sem fins lucrativos? Solicite tempo grátis de Pro ou Business e crédito Cloud para Deploy e Databases.

  • Plano Pro ou Business por até um ano, para Deploy e Databases juntos
  • Crédito Cloud adicionado ao seu saldo
  • Para sua conta pessoal ou toda a sua equipe
  • Lida por uma pessoa, geralmente respondida em poucos dias
  • Open source
  • Estudantes
  • Sem fins lucrativos
  • Startups
  • Educadores
  • Hackathons

Dúvidas

O que conta como minuto de CI?

Cada minuto iniciado de um job conta, arredondado para cima por job. Um minuto em um runner médio conta duas vezes, e em um runner grande, quatro vezes. O tempo na fila não conta, e os jobs que uma reexecução mantém da tentativa anterior não custam nada.

Onde os jobs rodam?

Em servidores que o próprio Enzonic opera, os mesmos que sustentam o Enzonic Deploy e o Databases. Cada job tem sua própria sandbox gVisor, com sistema de arquivos e rede próprios, e seus contêineres de serviço ficam ao lado dela. Os jobs nunca compartilham o kernel de uma máquina com o código de outro cliente.

Por que os jobs começam tão rápido?

As sandboxes são inicializadas com antecedência e descongeladas quando um job chega, em vez de iniciar uma máquina para cada job. O checkout vem de um espelho local do seu repositório, e os caches de dependências são vinculados a partir do disco local em vez de baixados. A maior parte de uma execução são os seus próprios passos.

Quais sistemas operacionais os jobs podem usar?

Somente Linux. Os jobs rodam em contêineres Linux; runners Windows e macOS não estão disponíveis.

Posso manter meus fluxos de trabalho do GitHub Actions?

Sim, desde que usem o subconjunto compatível: passos run, matrix, needs, services, container, e as ações checkout, setup-node, setup-python, setup-go, setup-java, setup-bun, pnpm, cache e artifact. Um fluxo de trabalho que use qualquer outra coisa é ignorado com uma mensagem clara, e os outros fluxos continuam rodando.

O que acontece com os segredos e as pull requests de forks?

Os segredos são criptografados, chegam apenas aos jobs que os usam e ficam ocultos nos logs. Pull requests de forks rodam sem segredos, sem token do GitHub e sem salvar caches, ou não rodam de forma alguma, se preferir.

Como os resultados chegam ao GitHub?

Como checks, com as linhas com erro anotadas na pull request, quando o GitHub App tem a permissão Checks. Sem ela, como status de commit. Regras de proteção de branch podem exigi-los como qualquer outro check.

E se uma execução falhar?

Você recebe um e-mail, se quiser, e um botão Corrigir com a Enzica no job com falha. A Enzica lê o log e a sua configuração, envia uma correção para uma nova branch enzica/ci-fix e roda o pipeline nela. Suas branches nunca são alteradas; você faz o merge da correção se estiver certa.

Preciso hospedar meu app no Enzonic?

Não. O CI funciona com qualquer repositório do GitHub. Faça deploy a partir de um job para onde você hospeda, com um segredo para o token, ou para o Enzonic Deploy.

Quais imagens um job pode usar?

Qualquer imagem de contêiner pública: node, python, golang, eclipse-temurin, oven/bun ou a sua. Serviços como postgres:17 e valkey/valkey:8 iniciam antes dos passos e podem ser acessados em localhost e pelo nome do serviço.

Seu próximo push pode rodar aqui.

Envie o resultado também: O Enzonic Deploy hospeda apps web de graça.