self-hosted CI runner की एक असहज आदत है: वे सब कुछ याद रखते हैं। कैश, टोकन, एक डिप्लॉय कुंजी जो किसी ने पिछले वसंत में "अस्थायी रूप से" जोड़ी थी। आपकी अपनी ब्रांचों के लिए यह ठीक है। मुश्किल तब शुरू होती है जब किसी ऐसे व्यक्ति का pull request आता है जिसका नाम भी आपने नहीं सुना — या आपके अपने AI एजेंट का, जिसने ऐसा पैच लिखा है जिसे अभी किसी ने पढ़ा तक नहीं।
साफ़ जवाब है: हर रन के लिए एक मशीन। क्लोन करें, इंस्टॉल करें, टेस्ट करें, मशीन फेंक दें।
एक रन कैसा दिखता है
सैंडबॉक्स एक 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)
टोकन आपके CI सीक्रेट्स में EQVPS_API_KEY के नाम से रहता है। आपके CI की और कोई चीज़ — न डिप्लॉय कुंजियाँ, न क्लाउड क्रेडेंशियल — सैंडबॉक्स में नहीं जाती। जब with ब्लॉक ख़त्म होता है, सैंडबॉक्स मिटा दिया जाता है, भले ही जॉब बीच में क्रैश हो गई हो।
टेस्ट रन ख़ुद एक बैकग्राउंड टास्क है, क्योंकि एक सिंक्रोनस कमांड 55 सेकंड पर रुक जाती है। बैकग्राउंड टास्क चलते हुए अपना आउटपुट भेजता रहता है और सैंडबॉक्स के TTL तक चल सकता है — यहाँ इसे 30 मिनट रखा गया है ताकि अटका हुआ टेस्ट बिल न बढ़ा सके।
वे सीमाएँ जिनसे आप सच में टकराएँगे
इनके बारे में साफ़ बताने से आपकी पूरी दोपहर बच जाती है।
एक साथ चलना। एक खाते में 20 सैंडबॉक्स हो सकते हैं, लेकिन एक समय पर सिर्फ़ 2 कमांड चलती हैं। CI के लिए यानी दो जॉब सच में समानांतर। एक साथ आए दस PR कतार में लगेंगे। अगर आपकी पाइपलाइन टेस्ट को 16 worker में बाँटती है, तो मुख्य पाइपलाइन के लिए यह सही औज़ार नहीं है — उसे VPS पर अपने runner पर रखें और सैंडबॉक्स का उपयोग अविश्वसनीय लेन के लिए करें।
अंदर कंटेनर नहीं। सैंडबॉक्स के साथ 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 जाँच के लिए सैंडबॉक्स और AI एजेंटों के लिए सैंडबॉक्स।
टिप्पणियाँ
अभी तक कोई टिप्पणी नहीं। पहले बनें।