แซนด์บ็อกซ์สำหรับ CI: รันเทสต์แบบแยกส่วน ไม่ถึงหนึ่งเซนต์ต่อครั้ง

self-hosted CI runner มีนิสัยน่าอึดอัดอยู่อย่างหนึ่ง คือจำทุกอย่าง แคช โทเค็น คีย์ deploy ที่ใครสักคนเพิ่มไว้ "ชั่วคราว" เมื่อฤดูใบไม้ผลิที่แล้ว สำหรับ branch ของคุณเองนั่นไม่ใช่ปัญหา ปัญหาเริ่มเมื่อมี pull request มาจากคนที่คุณไม่เคยได้ยินชื่อ หรือจาก AI agent ของคุณเอง ที่เขียนแพตช์ซึ่งยังไม่มีใครอ่าน

คำตอบที่สะอาดคือหนึ่งเครื่องต่อการรันหนึ่งครั้ง โคลน ติดตั้ง เทสต์ แล้วทิ้งเครื่องไป

การรันหนึ่งครั้งหน้าตาเป็นอย่างไร

แซนด์บ็อกซ์คือ Firecracker microVM ที่เริ่มทำงานในราวหนึ่งวินาที พร้อม Python 3.12, Node.js 22, git และ curl อินเทอร์เน็ตขาออกใช้ได้ ดังนั้น git clone และ pip install -r requirements.txt ทำงานตามปกติ ไม่มีพอร์ตขาเข้า ระหว่างที่รันอยู่ ไม่มีอะไรเชื่อมต่อเข้ามายังสภาพแวดล้อมทดสอบได้

จากมุมของงาน CI ทั้งหมดนี้คือสคริปต์สั้น ๆ นี่คือเวอร์ชันที่ใช้ Python SDK เรียกจากงาน 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)

โทเค็นเก็บไว้ใน secret ของ CI ชื่อ EQVPS_API_KEY ไม่มีอะไรอื่นจาก CI ของคุณเข้าไปในแซนด์บ็อกซ์ ทั้งคีย์ deploy และข้อมูลรับรองคลาวด์ เมื่อบล็อก with จบ แซนด์บ็อกซ์จะถูกลบ แม้งานจะล่มกลางทางก็ตาม

ตัวการรันเทสต์เองเป็น งานเบื้องหลัง เพราะคำสั่งซิงโครนัสหนึ่งคำสั่งจะหยุดที่ 55 วินาที งานเบื้องหลังส่งเอาต์พุตออกมาระหว่างทำงาน และรันต่อได้จนถึง TTL ของแซนด์บ็อกซ์ ซึ่งในที่นี้ตั้งไว้ 30 นาที เพื่อไม่ให้เทสต์ที่ค้างดันบิลขึ้น

ข้อจำกัดที่คุณจะเจอจริง

การบอกตรง ๆ เรื่องนี้ช่วยประหยัดเวลาคุณได้ทั้งบ่าย

การรันพร้อมกัน บัญชีหนึ่งมีแซนด์บ็อกซ์ได้ 20 ตัว แต่ ทำงานพร้อมกันได้เพียง 2 คำสั่ง สำหรับ CI คือสองงานที่รันขนานกันจริง ๆ PR สิบตัวที่มาพร้อมกันจะต้องเข้าคิว ถ้า pipeline ของคุณแบ่งเทสต์ไปยัง 16 worker นี่ไม่ใช่เครื่องมือที่เหมาะกับ pipeline หลัก ให้เก็บไว้บน runner ของคุณเองบน VPS และใช้แซนด์บ็อกซ์กับเลนที่ไม่น่าเชื่อถือ

ไม่มีคอนเทนเนอร์ข้างใน แซนด์บ็อกซ์ไม่มี Docker มาด้วย unit test และ integration test ที่ต้องใช้คอนเทนเนอร์ Postgres จะใช้ไม่ได้ตามที่เป็นอยู่ ส่วนเทสต์ที่ใช้ SQLite หรือออบเจ็กต์จำลองในหน่วยความจำใช้ได้

ไฟล์ การอัปโหลดและดาวน์โหลดผ่าน API ได้สูงสุด 5 MB ต่อไฟล์ ให้ดึงโค้ดด้วย git ภายในแซนด์บ็อกซ์แทนการอัปโหลดไฟล์บีบอัด

ค่าใช้จ่าย

คุณจ่ายค่า vCPU และ RAM ของแพ็กเกจรายวินาที ขั้นต่ำ 60 วินาที จากยอดเงินเติมล่วงหน้า ไม่มีค่าสมาชิก

ที่ราคานี้ คำถามที่น่าสนใจไม่ใช่ค่าใช้จ่าย แต่คือเทสต์ของคุณจบทันเวลาที่ตั้งไว้หรือไม่ ให้ตั้ง TTL เผื่อไว้มากกว่าการรันที่ผ่านซึ่งช้าที่สุดของคุณเล็กน้อย

การแบ่งงานที่สมเหตุสมผล

คำแนะนำของเรา: เก็บ branch ที่เชื่อถือได้ไว้บน runner ที่เร็วและมีแคชของคุณ ส่งทุกอย่างที่คุณไม่ได้เขียนเอง ไม่ว่าจะเป็น fork ผู้ร่วมพัฒนาจากภายนอก หรือแพตช์ที่ agent สร้างขึ้น ผ่านแซนด์บ็อกซ์ก่อน ถ้าการรันในแซนด์บ็อกซ์ผ่านและมีคนดู diff แล้ว จึงเลื่อนขึ้นไปยัง pipeline ที่เชื่อถือได้

แบบนี้คุณจะมีเลนหนึ่งที่ความเร็วและแคชสำคัญ และอีกเลนที่เครื่องสะอาดสำคัญ โดยไม่ต้องบังคับให้เครื่องมือเดียวทำทั้งสองอย่าง

เริ่มที่ ภาพรวมของแซนด์บ็อกซ์ และ คู่มือการเชื่อมต่อ บัญชีใหม่ได้เวลาแซนด์บ็อกซ์มูลค่า $1 ซึ่งพอสำหรับการรันเทสต์สั้น ๆ หลายร้อยครั้ง ทุกเมธอดที่ใช้ข้างต้นอยู่ใน เอกสารอ้างอิง SDK และกฎการคิดเงินที่แน่นอนอยู่ใน ข้อจำกัดและการคิดเงินของแซนด์บ็อกซ์

เกี่ยวข้อง: แซนด์บ็อกซ์สำหรับรีวิวโค้ดและตรวจ PR และ แซนด์บ็อกซ์สำหรับ AI agent