Vai al contenuto

CI per i tuoi repository GitHub
su server gestiti direttamente da noi.

Ogni push e pull request esegue i tuoi test in una sandbox su hardware Enzonic, già in funzione quando arriva il job, con log in tempo reale e un check su GitHub. Scrivi un breve .enzonic/ci.yml, oppure mantieni i workflow di GitHub Actions che hai già.

3000 minuti al mese gratis. Nessuna carta.

Vedi una configurazione
$ git push origin maina41c9e2Esecuzione #128 superata in 2m 18slint22stest (node 20)1m 08stest (node 22)1m 21sdeploy26spostgres:17 · healthyTutti i check sono stati superati4 job · Enzonic CI
Minuti CI al mese
job alla volta
per job
di cache delle dipendenze

Tutto ciò che serve a una pipeline, senza doverla tenere d’occhio

Runner, servizi, cache e log fanno parte del prodotto. Tu scrivi i passaggi.

Sandbox già in funzione

Ogni job ottiene la propria sandbox su hardware gestito da Enzonic, avviata in anticipo e scongelata quando arriva il job.

Job matrix e needs

Test su Node 20 e 22 insieme, poi deploy solo quando ogni cella è passata. I job attendono i job di cui hanno bisogno.

Servizi Postgres e Valkey

Avvia un database vero accanto ai test con una sola riga, con controllo dello stato prima del primo passaggio.

Cache

Conserva node_modules, i wheel di pip o l’output di build tra un’esecuzione e l’altra, con una chiave costruita dal tuo lockfile.

Artifact

Conserva report di copertura, build e screenshot, passali ai job successivi e scaricali per giorni.

Log in tempo reale

Segui ogni passaggio mentre gira, con i colori, raggruppato per passaggio, con i passaggi in errore già aperti per te.

Check su GitHub

Ogni job invia un check con annotazioni sulla pull request, pronto per la protezione del branch.

I tuoi workflow, invariati

Gran parte dei GitHub Actions funziona così com’è: matrix, servizi, container e le azioni di setup più comuni.

Pianificazioni

Test notturni o controlli settimanali delle dipendenze con una riga cron, in UTC.

Enzica corregge le esecuzioni fallite

Un clic su un job fallito: Enzica trova la causa, fa push di un branch di correzione ed esegue la pipeline su di esso.

L’attesa è finita, quindi l’esecuzione sono i tuoi passaggi

Gran parte del tempo della CI va per avviare una macchina, clonare e scaricare le dipendenze. Enzonic CI fa questo lavoro prima che arrivi il tuo job.

  1. 01

    Le sandbox si scongelano, non si avviano

    Un pool di sandbox viene avviato in anticipo. Quando arriva un job, ne viene scongelata una e assegnata al job, quindi non c’è nessuna macchina da avviare.

  2. 02

    Checkout da un mirror locale

    Ogni runner mantiene un mirror del tuo repository e scarica solo ciò che è cambiato, invece di clonare da GitHub per ogni job.

  3. 03

    Cache collegate dal disco locale

    Le cache delle dipendenze restano sul runner e vengono collegate al job, senza essere scaricate e decompresse prima.

Ogni job mostra dove è andato il suo tempo: coda, sandbox, checkout, dipendenze, servizi, cache e passaggi.

Un file nel tuo repository

Esegui il commit di .enzonic/ci.yml e fai push. I job girano nell’ordine stabilito da needs, le celle della matrix in parallelo, ognuna con i propri servizi, cache e artifact.

  • il lint gira per primo; entrambe le celle di test partono quando passa
  • ogni cella di test ha il proprio Postgres su localhost e come postgres:5432
  • i download npm arrivano dalla cache con chiave package-lock.json
  • la copertura viene conservata anche quando i test falliscono
  • il deploy gira solo su main, con un segreto che i log non mostrano mai
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 }}

Già su GitHub Actions?

Collega il repository e i tuoi .github/workflows girano qui senza modifiche, purché usino quanto elencato sotto. Tutto il resto viene rifiutato con un messaggio chiaro, mai saltato in silenzio.

Funziona così com’è

  • actions/checkoutViene sempre fatto il checkout del commit dell’esecuzione
  • actions/setup-node, setup-python, setup-go, setup-javaScegli l’immagine del job; cache: aggiunge la cache del gestore di pacchetti
  • oven-sh/setup-bun, pnpm/action-setupImmagine Bun, pnpm installato
  • actions/cache (and /restore, /save)Una cache del job, ripristinata per prima e salvata alla fine
  • actions/upload-artifact, download-artifactArtifact conservati con l’esecuzione e passati tra i job
  • strategy.matrix, needs, if, services, containerInclude include / exclude e fail-fast

Non supportato

  • Altri usi: action, action Docker, action composite e workflow riutilizzabili
  • Output di passaggi e job (steps.*.outputs, needs.*.outputs)
  • Runner Windows e macOS
  • pull_request_target
L’elenco completo della compatibilità

Prezzi

La CI è inclusa nel tuo piano Enzonic Cloud, lo stesso che copre Deploy e Databases. Inizia con il piano Free; passa a un piano superiore quando ti servono più minuti o runner più grandi. Solo runner Linux.

Piani di Enzonic CI
Ogni piano Cloud include la CI
Free
0 USD
Starter
5 USD / mese
4,17 USD al mese, fatturato annualmente
Consigliato
Pro
10 USD / mese
8,33 USD al mese, fatturato annualmente
Growth
19 USD / mese
15,83 USD al mese, fatturato annualmente
Business
29 USD / mese
24,17 USD al mese, fatturato annualmente
Minuti CI al mese30005000600015.00060.000
Job contemporanei2461020
Job più lungo360 min360 min360 min480 min720 min
Cache delle dipendenze2 GB5 GB10 GB20 GB50 GB
Artifact conservati90 giorni90 giorni90 giorni180 giorni400 giorni
Log conservati14 giorni30 giorni30 giorni60 giorni90 giorni

Grant per chi costruisce

Sviluppi open source, studi, insegni o gestisci un'organizzazione no profit? Richiedi tempo gratuito Pro o Business e credito Cloud per Deploy e Database.

  • Piano Pro o Business per un massimo di un anno, per Deploy e Database insieme
  • Credito Cloud aggiunto al tuo saldo
  • Per il tuo account personale o per tutto il team
  • Letta da una persona, di solito con risposta entro pochi giorni
  • Open source
  • Studenti
  • No profit
  • Startup
  • Docenti
  • Hackathon

Domande

Cosa conta come minuto CI?

Ogni minuto iniziato di esecuzione di un job, arrotondato per job. Un minuto su un runner medio conta il doppio e su uno grande quattro volte. Il tempo in coda non conta, e i job che una riesecuzione riprende dal tentativo precedente non costano nulla.

Dove girano i job?

Su server gestiti direttamente da Enzonic, gli stessi che sostengono Enzonic Deploy e Databases. Ogni job ottiene una propria sandbox gVisor con filesystem e rete dedicati, e i suoi container di servizio sono accanto ad essa. I job non condividono mai il kernel di una macchina con il codice di un altro cliente.

Perché i job partono così in fretta?

Le sandbox vengono avviate in anticipo e scongelate quando arriva un job, invece di avviare una macchina per ogni job. Il checkout arriva da un mirror locale del tuo repository, e le cache delle dipendenze vengono collegate dal disco locale invece di essere scaricate. Gran parte di un’esecuzione sono i tuoi passaggi.

Quali sistemi operativi possono usare i job?

Solo Linux. I job girano in container Linux; i runner Windows e macOS non sono disponibili.

Posso tenere i miei workflow di GitHub Actions?

Sì, se restano nel sottoinsieme supportato: passaggi run, matrix, needs, services, container e le azioni checkout, setup-node, setup-python, setup-go, setup-java, setup-bun, pnpm, cache e artifact. Un workflow che usa altro viene saltato con un messaggio chiaro, e gli altri workflow continuano a girare.

Cosa succede con i segreti e le pull request da fork?

I segreti sono cifrati, arrivano solo ai job che li usano e vengono mascherati nei log. Le pull request da fork girano senza segreti, senza token GitHub e senza salvare cache, oppure non girano affatto se preferisci.

Come arrivano i risultati su GitHub?

Come check, con le righe che hanno fallito annotate sulla pull request, quando la GitHub App ha il permesso Checks. Senza, come stato del commit. Le regole di protezione del branch possono richiederli come qualsiasi altro check.

Cosa succede se un’esecuzione fallisce?

Ricevi un’email, se la vuoi, e un pulsante Correggi con Enzica sul job fallito. Enzica legge il log e la tua configurazione, fa push di una correzione su un nuovo branch enzica/ci-fix ed esegue la pipeline su di esso. I tuoi branch non vengono mai modificati; unisci la correzione se è giusta.

Devo ospitare la mia app su Enzonic?

No. La CI funziona con qualsiasi repository GitHub. Puoi fare il deploy da un job dovunque tu ospiti, con un segreto per il token, oppure su Enzonic Deploy.

Quali immagini può usare un job?

Qualsiasi immagine container pubblica: node, python, golang, eclipse-temurin, oven/bun o una tua. I servizi come postgres:17 e valkey/valkey:8 partono prima dei passaggi e sono raggiungibili su localhost e tramite il nome del servizio.

Il tuo prossimo push può girare qui.

Pubblica anche il risultato: Enzonic Deploy ospita gratis le web app.