صندوق رمل لمراجعة الشيفرة وفحوص طلبات السحب: أثبت أن الرقعة تعمل قبل أن توافق عليها

الفروقات تُظهر ما تدّعي الرقعة فعله. لكنها لا تُظهر إن كان الخطأ قد اختفى حقًا، أو إن كان الفرع الجديد من if يُنفَّذ أصلًا، أو إن كان تحديث إحدى الاعتماديات يكسر الاستيراد عند التثبيت النظيف. يعرف المراجعون ذلك، ولهذا تنتهي مراجعات كثيرة بعبارة "LGTM، بشرط أن تنجح الاختبارات".

مع الرقع التي يكتبها الذكاء الاصطناعي تتسع هذه الفجوة. النموذج ينتج بسرعة شيفرة تبدو معقولة، والمعقول هو تحديدًا ما يفلت من مراجع متعب. الحل الرخيص هو تشغيل التغيير قبل أن يوافق عليه أحد — في مكان لا يستطيع فيه إيذاء أي شيء.

الفحص: base و head والاختبارات

أقوى دليل يمكن أن تقدمه رقعة هو إعادة إنتاج تفشل على الشيفرة القديمة وتنجح على الجديدة. صندوق الرمل يحوّل ذلك إلى سكربت من 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، فالرقعة تصلح ما تدّعي إصلاحه. انشر هذا السطر مع ملخص الاختبارات كتعليق على طلب السحب، وسيبدأ المراجع من الحقائق.

تعمل حزمة الاختبارات كمهمة في الخلفية لأن الأمر المتزامن الواحد يتوقف عند 55 ثانية. ويحدّ الـ TTL البالغ 30 دقيقة من المدة التي يمكن أن يُحاسَب فيها تشغيل عالق.

وكلاء مراجعة يشغّلون الشيفرة

الفكرة نفسها تنجح مع مراجع يعمل بالذكاء الاصطناعي. عند اتصاله عبر خادم MCP، يحصل الوكيل على أدوات صناديق الرمل: إنشاء صندوق، وتنفيذ أمر، ورفع الملفات وتنزيلها. بدل أن يكتب "قد يكسر هذا التوافق مع Python 3.8"، يجلب الفرع، ويشغّل الشيفرة، ويقتبس الـ traceback — أو يبلغ بأن كل شيء على ما يرام.

امنح هذا الوكيل حدًا للإنفاق ورمز وصول للقراءة فقط، وحدّد الأدوات التي يمكنه استدعاؤها دون سؤال. تسرد ضوابط أمان MCP كل أداة بحسب مستوى خطورتها.

أي باقة

تُحاسَب صناديق الرمل المؤقتة بالثانية بحد أدنى 60 ثانية. إن أراد المراجع العودة إلى البيئة نفسها على مدى يومين أو ثلاثة، فأنشئها كـ persistent: تحتفظ بقرصها حتى 30 يومًا وتُحاسَب عن كل ساعة تبدأ، لذا فإن صندوق standard محفوظًا لمراجعة مدتها يومان يكلّف نحو 3.17 دولار. احذفه عند دمج طلب السحب.

حدود تستحق المعرفة

• أمران في الوقت نفسه لكل حساب. يكفيان تمامًا للمراجعات التي تتم الواحدة تلو الأخرى. إن فحصت عشرات طلبات السحب دفعة واحدة، فستنتظر في الطابور.
• لا منافذ واردة. لا يمكنك فتح التطبيق في متصفح. شغّله في الداخل واختبره عبر curl localhost من أمر ثانٍ.
• لا Docker في الداخل. الاختبارات التي تشغّل حاويات مكانها runner على VPS.
• الإنترنت الصادر مفتوح. وهذا ما يجعل pip install يعمل. لا تضع في صندوق الرمل شيئًا لن تعطيه لكاتب الرقعة.

البداية

تحصل الحسابات الجديدة على رصيد 1 دولار من وقت صناديق الرمل، وهو يغطي أكثر من مئة مراجعة على باقة standard. في صفحة صناديق الرمل تجد الباقات، وفي مرجع SDK كل طريقة مستخدمة أعلاه، وفي SDK بايثون في 5 دقائق خطوات الإعداد.

ذو صلة: تشغيلات CI معزولة لخط الأنابيب كاملًا، وصندوق رمل لوكلاء الذكاء الاصطناعي للوكلاء الذين يكتبون الشيفرة من الأساس.