Sandbox CI-სთვის: იზოლირებული ტესტები თითო გაშვებაზე ერთ ცენტზე ნაკლებად

CI-ის self-hosted runner-ებს ერთი უხერხული თვისება აქვთ: ყველაფერი ახსოვთ. ქეში, ტოკენები, deploy-ის გასაღები, რომელიც ვიღაცამ შარშან გაზაფხულზე „დროებით“ დაამატა. საკუთარი ბრენჩებისთვის ეს ნორმალურია. პრობლემა იწყება მაშინ, როცა pull request მოდის ადამიანისგან, რომლის სახელიც არასდროს გსმენიათ — ან თქვენივე AI აგენტისგან, რომელმაც დაწერა პაჩი, რომელიც ჯერ არავის წაუკითხავს.

სუფთა პასუხია ერთი მანქანა თითო გაშვებაზე. დაკლონე, დააყენე, გატესტე, მანქანა გადააგდე.

როგორ გამოიყურება გაშვება

sandbox არის 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-დან სხვა არაფერი — არც deploy-ის გასაღებები, არც ღრუბლის მონაცემები — sandbox-ში არ ხვდება. როცა with ბლოკი სრულდება, sandbox იშლება, მაშინაც კი, თუ ამოცანა შუა გზაზე ჩავარდა.

თავად ტესტების გაშვება ფონური ამოცანაა, რადგან ერთი სინქრონული ბრძანება 55 წამზე ჩერდება. ფონური ამოცანა მუშაობისას გამონატანს გადასცემს და შეუძლია sandbox-ის TTL-მდე გაგრძელდეს — აქ ის 30 წუთზეა დაყენებული, რომ გაჭედილმა ტესტმა ანგარიში არ გაზარდოს.

ლიმიტები, რომლებსაც მართლა წააწყდებით

მათზე გულწრფელობა მთელ ნაშუადღევს დაგიზოგავთ.

ერთდროულობა. ანგარიშს შეუძლია ჰქონდეს 20 sandbox, მაგრამ ერთდროულად მხოლოდ 2 ბრძანება სრულდება. CI-სთვის ეს არის ორი ამოცანა, რომლებიც მართლა პარალელურად მუშაობს. ერთად მოსული ათი PR რიგში დადგება. თუ თქვენი pipeline ტესტებს 16 worker-ზე ანაწილებს, მთავარი pipeline-ისთვის ეს არასწორი ინსტრუმენტია — დატოვეთ ის თქვენს runner-ებზე VPS-ზე და sandbox-ები არასანდო ზოლისთვის გამოიყენეთ.

შიგნით კონტეინერები არ არის. Docker sandbox-ს არ მოყვება. unit და integration ტესტები, რომლებსაც Postgres კონტეინერი სჭირდება, ისე, როგორც არის, არ იმუშავებს; ტესტები SQLite-ზე ან მეხსიერებაში არსებულ ყალბ ობიექტზე კი იმუშავებს.

ფაილები. API-ით ატვირთვა და ჩამოტვირთვა თითო ფაილზე 5 MB-მდეა. არქივის ატვირთვის ნაცვლად კოდი sandbox-ის შიგნით git-ით ჩამოიტანეთ.

რა ღირს

ტარიფის vCPU-სა და RAM-ს წამობრივად იხდით, მინიმუმ 60 წამი, წინასწარ გადახდილი ბალანსიდან — გამოწერის გარეშე.

ამ ფასებში საინტერესო კითხვა ღირებულება კი არა, ის არის, დაასრულებენ თუ არა ტესტები მითითებულ დროში. TTL-ს თქვენს ყველაზე ნელ წარმატებულ გაშვებაზე ცოტა მეტი მარაგი მიეცით.

გონივრული დაყოფა

ჩვენი რეკომენდაცია: სანდო ბრენჩები დატოვეთ თქვენს სწრაფ, ქეშიან runner-ზე. ყველაფერი, რაც თქვენ არ დაგიწერიათ — fork-ები, გარე კონტრიბუტორები, აგენტების შექმნილი პაჩები — ჯერ sandbox-ში გაატარეთ. თუ sandbox-ში გაშვება წარმატებულია და ადამიანმა diff ნახა, გადაიტანეთ ის სანდო pipeline-ში.

ასე გექნებათ ერთი ზოლი, სადაც სიჩქარე და ქეში მნიშვნელოვანია, და მეორე, სადაც სუფთა მანქანაა მნიშვნელოვანი — ისე, რომ ერთ ინსტრუმენტს ორივეს შესრულება არ აიძულოთ.

დაიწყეთ sandbox-ების მიმოხილვით და დაკავშირების სახელმძღვანელოთი — ახალი ანგარიშები იღებს $1-ის sandbox-დროს, რაც რამდენიმე ასეულ მოკლე ტესტს ყოფნის. ზემოთ გამოყენებული ყველა მეთოდი არის SDK-ის ცნობარში, ბილინგის ზუსტი წესები კი sandbox-ის ლიმიტებსა და ბილინგში.

დაკავშირებული: sandbox კოდის რევიუსა და PR შემოწმებისთვის და Sandbox AI აგენტებისთვის.