Sandbox per la CI: test isolati a meno di un centesimo per esecuzione

I runner CI self-hosted hanno una proprietà scomoda: ricordano tutto. Cache, token, una chiave di deploy che qualcuno ha aggiunto «temporaneamente» la primavera scorsa. Per i tuoi branch va bene. Il problema nasce quando arriva una pull request da qualcuno di cui non hai mai sentito parlare, o dal tuo stesso agente IA, che ha scritto una patch che nessuno ha ancora letto.

La risposta pulita è una macchina per esecuzione. Clonare, installare, testare, buttare via la macchina.

Com'è fatta un'esecuzione

Una sandbox è una microVM Firecracker che si avvia in circa un secondo con Python 3.12, Node.js 22, git e curl. L'accesso a internet in uscita funziona, quindi git clone e pip install -r requirements.txt si comportano come al solito. Non ci sono porte in ingresso: niente può raggiungere l'ambiente di test mentre è in esecuzione.

Da un job CI, il tutto è uno script breve. Eccolo con l'SDK Python, richiamabile da qualsiasi job CI:

import os, sys
from eqvps import Sandbox

repo, ref = os.environ["REPO_URL"], os.environ["PR_SHA"]

with Sandbox.create(tariff="standard", ttl=1800) as sb:
    sb.exec(f"git clone {repo} /root/app && cd /root/app && git checkout {ref}", timeout=55)
    sb.exec("cd /root/app && pip install -r requirements.txt", timeout=55)
    task = sb.exec("cd /root/app && python3 -m pytest -q", background=True)
    result = task.wait(on_output=lambda out, err: print(out, end=""))
sys.exit(result.exit_code or 0)

Il token vive nei secret della tua CI come EQVPS_API_KEY. Nient'altro della tua CI — né chiavi di deploy, né credenziali cloud — entra nella sandbox. Quando il blocco with termina, la sandbox viene eliminata, anche se il job si è bloccato a metà.

L'esecuzione dei test è un'attività in background, perché un singolo comando sincrono si ferma a 55 secondi. Un'attività in background trasmette l'output mentre lavora e può continuare fino al TTL della sandbox, qui impostato a 30 minuti perché un test bloccato non faccia lievitare il conto.

I limiti che incontrerai davvero

Parlarne con franchezza ti fa risparmiare un pomeriggio.

Concorrenza. Un account può avere 20 sandbox, ma solo 2 comandi vengono eseguiti contemporaneamente. Per la CI sono due job davvero in parallelo. Dieci PR arrivate insieme finiranno in coda. Se la tua pipeline distribuisce i test su 16 worker, questo non è lo strumento per la pipeline principale: tienila sui tuoi runner su un VPS e usa le sandbox per la corsia non fidata.

Niente container all'interno. Docker non è incluso nella sandbox. I test unitari e di integrazione che richiedono un container Postgres non funzioneranno così come sono; quelli su SQLite o su un fake in memoria sì.

File. Upload e download tramite API arrivano fino a 5 MB per file. Scarica il codice con git dentro la sandbox invece di caricare un archivio.

Quanto costa

Paghi vCPU e RAM della tariffa al secondo, minimo 60 secondi, da un credito prepagato, senza abbonamento.

A questi prezzi la domanda interessante non è il costo, ma se i tuoi test finiscono entro il tempo impostato. Lascia al TTL un po' di margine oltre la tua esecuzione verde più lenta.

Una divisione sensata

Il nostro consiglio: tieni i branch fidati sul tuo runner veloce con cache. Fai passare prima da una sandbox tutto ciò che non hai scritto tu: fork, contributori esterni, patch generate da agenti. Se l'esecuzione nella sandbox è verde e una persona ha guardato il diff, promuovila alla pipeline fidata.

Così hai una corsia in cui contano velocità e cache e un'altra in cui conta una macchina pulita, senza costringere un solo strumento a essere entrambe le cose.

Parti dalla panoramica delle sandbox e dalla guida alla connessione: i nuovi account ricevono $1 di tempo sandbox, sufficiente per qualche centinaio di esecuzioni brevi. Ogni metodo usato sopra è nel riferimento dell'SDK, e le regole di fatturazione esatte in limiti e fatturazione delle sandbox.

Correlati: sandbox per code review e controlli delle PR e sandbox per agenti IA.