Sandbox til CI: isolerede testkørsler for under en cent stykket

Self-hosted CI-runners har én akavet egenskab: de husker alt. Caches, tokens, en deploy-nøgle, som nogen tilføjede „midlertidigt“ sidste forår. For dine egne branches er det fint. Det bliver et problem, så snart en pull request kommer fra en, du aldrig har hørt om – eller fra din egen AI-agent, der skrev en patch, som ingen har læst endnu.

Det rene svar er én maskine pr. kørsel. Klon, installer, test, smid maskinen væk.

Sådan ser en kørsel ud

En sandbox er en Firecracker-microVM, der starter på cirka et sekund med Python 3.12, Node.js 22, git og curl. Udgående internet virker, så git clone og pip install -r requirements.txt opfører sig som normalt. Der er ingen indgående porte – intet kan nå testmiljøet, mens det kører.

Fra et CI-job er det hele et kort script. Her er det med Python-SDK'et, kaldt fra et hvilket som helst CI-job:

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)

Tokenet ligger i dine CI-hemmeligheder som EQVPS_API_KEY. Intet andet fra din CI – ingen deploy-nøgler, ingen cloud-legitimationsoplysninger – kommer ind i sandboxen. Når with-blokken slutter, slettes sandboxen, også hvis jobbet gik ned halvvejs.

Selve testkørslen er en baggrundsopgave, fordi en enkelt synkron kommando stopper efter 55 sekunder. En baggrundsopgave streamer output, mens den arbejder, og kan fortsætte indtil sandboxens TTL – her sat til 30 minutter, så en test, der hænger, ikke kan løbe en regning op.

De grænser, du faktisk løber ind i

At være ærlig om dem sparer dig en eftermiddag.

Samtidighed. En konto kan have 20 sandboxe, men kun 2 kommandoer udføres samtidig. For CI er det to jobs, der reelt kører parallelt. Ti PR'er, der kommer på én gang, stiller sig i kø. Hvis din pipeline fordeler tests på 16 workers, er det her det forkerte værktøj til hovedpipelinen – behold den på dine egne runners på en VPS, og brug sandboxe til den upålidelige bane.

Ingen containere indeni. Docker følger ikke med i sandboxen. Unit- og integrationstests, der kræver en Postgres-container, virker ikke uden videre; tests mod SQLite eller en fake i hukommelsen gør.

Filer. Upload og download via API'et går op til 5 MB pr. fil. Hent koden med git inde i sandboxen i stedet for at uploade et arkiv.

Hvad det koster

Du betaler for tariffens vCPU og RAM pr. sekund, mindst 60 sekunder, fra en forudbetalt saldo – uden abonnement.

Ved de priser er det interessante spørgsmål ikke prisen, men om dine tests bliver færdige inden for den tid, du har sat. Giv TTL lidt luft over din langsomste grønne kørsel.

En fornuftig opdeling

Vores anbefaling: behold betroede branches på din hurtige runner med cache. Send alt, du ikke selv har skrevet – forks, eksterne bidragydere, agentgenererede patches – gennem en sandbox først. Er sandbox-kørslen grøn, og har et menneske kigget på diffen, så rykker du den op i den betroede pipeline.

Så har du én bane, hvor fart og cache tæller, og én, hvor en ren maskine tæller, uden at tvinge ét værktøj til at være begge dele.

Start med oversigten over sandboxe og forbindelsesguiden – nye konti får $1 i sandbox-tid, hvilket dækker et par hundrede korte testkørsler. Alle metoder brugt ovenfor står i SDK-referencen, og de præcise afregningsregler i grænser og afregning for sandboxe.

Relateret: sandbox til kodegennemgang og PR-tjek og sandbox til AI-agenter.