در CI، runnerهای خودمیزبان یک ویژگی آزاردهنده دارند: همهچیز را به خاطر میسپارند. کشها، توکنها، کلید استقراری که کسی بهار گذشته «موقتاً» اضافه کرده است. برای شاخههای خودتان مشکلی نیست. مشکل از لحظهای شروع میشود که pull request از کسی میرسد که هرگز اسمش را نشنیدهاید — یا از عامل هوش مصنوعی خودتان که وصلهای نوشته که هنوز کسی آن را نخوانده است.
پاسخ تمیز این است: یک ماشین برای هر اجرا. کلون کنید، نصب کنید، تست کنید، ماشین را دور بیندازید.
یک اجرا چه شکلی دارد
سندباکس یک Firecracker microVM است که در حدود یک ثانیه با Python 3.12، Node.js 22، git و curl بالا میآید. اینترنت خروجی کار میکند، پس git clone و pip install -r requirements.txt مثل همیشه رفتار میکنند. پورت ورودی وجود ندارد — تا وقتی محیط تست در حال اجراست، هیچ چیز نمیتواند به آن وصل شود.
از دید یک کار CI، کل ماجرا یک اسکریپت کوتاه است. این نسخه با 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)
توکن در رازهای CI شما با نام EQVPS_API_KEY نگهداری میشود. هیچ چیز دیگری از CI شما — نه کلید استقرار و نه اعتبارنامه ابری — وارد سندباکس نمیشود. وقتی بلوک with تمام شود، سندباکس حذف میشود، حتی اگر کار در میانه راه از کار افتاده باشد.
خود اجرای تست یک کار پسزمینه است، چون یک فرمان همزمان در ثانیه 55 متوقف میشود. کار پسزمینه در حین اجرا خروجیاش را میفرستد و میتواند تا TTL سندباکس ادامه پیدا کند — که اینجا روی 30 دقیقه تنظیم شده تا یک تست گیرکرده نتواند صورتحساب را بالا ببرد.
محدودیتهایی که واقعاً به آنها برمیخورید
صراحت درباره آنها یک بعدازظهر کامل برایتان صرفهجویی میکند.
همزمانی. یک حساب میتواند 20 سندباکس داشته باشد، اما فقط 2 فرمان همزمان اجرا میشوند. برای CI یعنی دو کار که واقعاً موازی اجرا میشوند. ده PR که با هم برسند، در صف میمانند. اگر خط لوله شما تستها را بین 16 worker تقسیم میکند، این ابزار برای خط لوله اصلی مناسب نیست — آن را روی runnerهای خودتان روی VPS نگه دارید و سندباکسها را برای مسیر غیرقابلاعتماد به کار ببرید.
داخلش کانتینر نیست. Docker همراه سندباکس نیست. تستهای واحد و یکپارچگی که به کانتینر Postgres نیاز دارند همانطور که هستند کار نمیکنند؛ تستهایی که با SQLite یا یک شیء جعلی در حافظه کار میکنند، کار میکنند.
فایلها. بارگذاری و دریافت از طریق API حداکثر 5 MB برای هر فایل است. به جای بارگذاری آرشیو، کد را داخل سندباکس با git دریافت کنید.
هزینهاش چقدر است
هزینه vCPU و RAM تعرفه را ثانیهای، با حداقل 60 ثانیه، از موجودی پیشپرداخت میپردازید — بدون اشتراک.
| اجرا | تعرفه | هزینه تقریبی |
|---|---|---|
| بررسی سبک + تستهای واحد، 1 دقیقه | small (0.5 vCPU, 1 GB) | $0.0006 |
| مجموعه کامل، 3 دقیقه | standard (1 vCPU, 2 GB) | $0.0033 |
| ساخت + تست، 10 دقیقه | plus (2 vCPU, 4 GB) | $0.022 |
با این قیمتها، پرسش جالب هزینه نیست، بلکه این است که آیا تستها در زمانی که تعیین کردهاید تمام میشوند. به TTL کمی بیشتر از کندترین اجرای موفقتان فرصت بدهید.
تقسیم کار معقول
پیشنهاد ما: شاخههای مورد اعتماد را روی runner سریع و دارای کش خودتان نگه دارید. هر چیزی را که خودتان ننوشتهاید — forkها، مشارکتکنندگان بیرونی، وصلههایی که عاملها ساختهاند — اول از سندباکس عبور دهید. اگر اجرای سندباکس موفق بود و یک انسان diff را دید، آن را به خط لوله مورد اعتماد ارتقا دهید.
اینطور یک مسیر دارید که در آن سرعت و کش مهم است و مسیری دیگر که در آن ماشین تمیز مهم است، بدون اینکه یک ابزار را مجبور کنید هر دو باشد.
از معرفی سندباکسها و راهنمای اتصال شروع کنید — حسابهای جدید 1 دلار زمان سندباکس دریافت میکنند که برای چند صد اجرای کوتاه تست کافی است. همه متدهایی که بالا به کار رفته در مرجع SDK هستند و قواعد دقیق صورتحساب در محدودیتها و صورتحساب سندباکس.
مرتبط: سندباکس برای بازبینی کد و بررسی PR و سندباکس برای عاملهای هوش مصنوعی.
نظرات
هنوز نظری نیست. اولین نفر باشید.