Sandbox კოდის რევიუსა და PR შემოწმებისთვის: აჩვენეთ, რომ პაჩი მუშაობს, სანამ მას დაამტკიცებთ

diff აჩვენებს, რის გაკეთებას ამტკიცებს პაჩი. ის არ აჩვენებს, მართლა გაქრა თუ არა შეცდომა, სრულდება თუ არა ოდესმე if-ის ახალი შტო, ან ტეხს თუ არა დამოკიდებულების განახლება import-ს სუფთა ინსტალაციისას. რევიუერებმა ეს იციან, ამიტომ ამდენი რევიუ სრულდება სიტყვებით „LGTM, თუ ტესტები გავა“.

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

შემოწმება: base, head, ტესტები

ყველაზე დამაჯერებელი მტკიცებულება, რისი წარმოდგენაც პაჩს შეუძლია, არის გამეორება, რომელიც ძველ კოდზე ვარდება და ახალზე გადის. sandbox ამას 20-ხაზიან სკრიპტად აქცევს. ეს არის Firecracker microVM Python 3.12-ით, Node.js 22-ით, git-ითა და curl-ით, რომელიც დაახლოებით ერთ წამში ირთვება:

import os
from eqvps import Sandbox

REPO, BASE, HEAD = os.environ["REPO_URL"], os.environ["BASE_SHA"], os.environ["HEAD_SHA"]

def repro(sb, ref):
    sb.exec(f"cd /root/app && git checkout -q {ref}", timeout=55)
    return sb.exec("cd /root/app && python3 /root/repro.py", timeout=55).exit_code

with Sandbox.create(tariff="standard", ttl=1800) as sb:
    sb.exec(f"git clone -q {REPO} /root/app", timeout=55)
    sb.exec("cd /root/app && pip install -q -r requirements.txt", timeout=55)
    sb.upload("/root/repro.py", open("repro.py").read())
    before, after = repro(sb, BASE), repro(sb, HEAD)
    tests = sb.exec("cd /root/app && python3 -m pytest -q", background=True).wait()
    print(f"repro on base: {before}, on head: {after}; tests: {tests.state}, exit {tests.exit_code}")

repro.py არის შეცდომის ანგარიშის კოდის ფრაგმენტი. თუ ის base-ზე არანულოვანი კოდით სრულდება, head-ზე კი ნულით, პაჩი ასწორებს იმას, რასაც ამტკიცებს. გამოაქვეყნეთ ეს ხაზი ტესტების შეჯამებასთან ერთად pull request-ზე კომენტარად და რევიუერი ფაქტებიდან დაიწყებს.

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

რევიუს აგენტები, რომლებიც კოდს უშვებენ

იგივე იდეა მუშაობს AI რევიუერისთვისაც. MCP სერვერით დაკავშირებულ აგენტს აქვს sandbox-ის ინსტრუმენტები: sandbox-ის შექმნა, ბრძანების გაშვება, ფაილების ატვირთვა და ჩამოტვირთვა. ნაცვლად იმისა, რომ დაწეროს „ამან შეიძლება Python 3.8-თან თავსებადობა გატეხოს“, ის ბრენჩს ჩამოიტანს, კოდს გაუშვებს და traceback-ს ციტირებს — ან იტყობინება, რომ ყველაფერი რიგზეა.

ასეთ აგენტს მიეცით ხარჯების ლიმიტი და მხოლოდ წაკითხვის ტოკენი, და გადაწყვიტეთ, რომელი ინსტრუმენტების გამოძახება შეუძლია კითხვის გარეშე. MCP-ის დამცავი ზომები ყველა ინსტრუმენტს რისკის დონის მიხედვით ჩამოთვლის.

რომელი ტარიფი

დროებითი sandbox-ები წამობრივად ითვლება, მინიმუმ 60 წამი. თუ რევიუერს სურს რამდენიმე დღის განმავლობაში იმავე გარემოში დაბრუნება, შექმენით ის როგორც persistent: ის დისკს 30 დღემდე ინახავს და ყოველ დაწყებულ საათზე ითვლება, ამიტომ ორდღიანი რევიუსთვის შენახული standard sandbox დაახლოებით $3.17 ღირს. წაშალეთ ის, როცა pull request შეერწყმება.

ლიმიტები, რომელთა ცოდნაც ღირს

• ორი ბრძანება ერთდროულად თითო ანგარიშზე. სრულიად საკმარისია რევიუებისთვის, რომლებიც ერთმანეთის მიყოლებით მიდის. თუ ათობით pull request-ს ერთად შეამოწმებთ, ისინი რიგში დადგებიან.
• შემომავალი პორტები არ არის. აპლიკაციას ბრაუზერში ვერ გახსნით. გაუშვით ის შიგნით და მეორე ბრძანებიდან curl localhost-ით გატესტეთ.
• შიგნით Docker არ არის. ტესტები, რომლებიც კონტეინერებს რთავს, VPS-ზე არსებულ runner-ს ეკუთვნის.
• გამავალი ინტერნეტი ღიაა. სწორედ ეს ამუშავებს pip install-ს. sandbox-ში ნუ ჩადებთ ისეთს, რასაც პაჩის ავტორს არ მისცემდით.

როგორ დავიწყოთ

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

დაკავშირებული: იზოლირებული CI ტესტები მთელი pipeline-ისთვის და Sandbox AI აგენტებისთვის იმ აგენტებისთვის, რომლებიც კოდს თავიდანვე წერენ.