کد
کد جایی است که از Status200 AI می‌خواهید در مخزن‌هایتان کار کند، همان‌طور که از یک عامل کدنویسی می‌خواهید: یک باگ را رفع کند، تست بنویسد، کد را توضیح دهد، تغییری بدهد. کد با کادری باز می‌شود که درخواستتان را در آن می‌نویسید، با مخزن و شاخه‌ای که در آن انتخاب می‌شوند و همهٔ وظایف زیر آن؛ صفحهٔ هر وظیفه گفت‌وگویی است که می‌توانید در آن پاسخ دهید. Status200 خودش هم از استثناها، ترِیس‌ها و بررسی‌ها وظیفه شروع می‌کند. یک Runner مخزن را کلون می‌کند، تغییر را روی یک شاخه تازه می‌نویسد، آن را می‌سازد و تست می‌کند و یک درخواست ادغام باز می‌کند. هر کدام را یک انسان بازبینی و ادغام می‌کند: Runner می‌تواند شاخه‌ها را push کند و درخواست ادغام باز کند، نه بیشتر.
این کار را از GitHub هم می‌توانید شروع کنید. در یک issue یا درخواست ادغام از Status200 GitHub App نام ببرید تا همان‌جا پیاده‌سازی، بازنگری یا بازبینی کند: GitHub App را ببینید. همان عامل، همان Runner و همان بودجه‌هاست؛ فقط محرک فرق دارد.
درخواست از هوش مصنوعی در یک مخزن
کد را باز کنید
محصولات > کد را باز کنید. کد با هوش مصنوعی چه کاری انجام دهد؟ باز می‌شود: کادری که درخواستتان را در آن می‌نویسید، با همهٔ وظایف زیر آن، تازه‌ترین‌ها اول. اگر هنوز مخزنی نباشد، به‌جای آن اتصال GitHub را پیشنهاد می‌کند (پیش از شروع را ببینید). مخازن در منوی کناری، مخزن‌هایی را فهرست می‌کند که هوش مصنوعی می‌تواند در آن‌ها کار کند، و آن‌هایی را که GitHub App دیگر به آن‌ها دسترسی ندارد زیر متصل نیست جمع می‌کند. صفحهٔ هر مخزن همان کادر را برای آن مخزن دارد.
مخزن و شاخه را انتخاب کنید
کادر با مخزنی شروع می‌شود که آخرین بار انتخاب کردید. مخزن دیگری را در ردیف پایین آن انتخاب کنید و کنارش شاخه‌ای را که وظیفه از آن شروع می‌شود: تا وقتی شاخهٔ دیگری انتخاب نکنید، شاخهٔ اصلی مخزن است که با پیش‌فرض مشخص شده. هوش مصنوعی شاخهٔ خودش را از شاخهٔ انتخابی شما می‌سازد و درخواست ادغامش را به همان باز می‌کند.
بگویید چه می‌خواهید
تغییر، باگ یا پرسش را به زبان خودتان بنویسید. تا وقتی چیزی خواسته نشده، کد زیر این‌ها را امتحان کنید چند نمونه پیشنهاد می‌دهد.
زمینه بیفزایید
روی افزودن زمینه کلیک کنید تا آنچه هوش مصنوعی لازم دارد به آن بدهید: یک فایل یا پوشه از مخزن، یک یادداشت، یک پیوند یا رکوردی از پروژه. Status200 هر رکورد را هنگام فرستادن درخواست، با مجوزهای شما می‌خواند و آنچه را به هوش مصنوعی داده شد نگه می‌دارد.
وظیفه را شروع کنید
روی شروع وظیفه کلیک کنید یا Enter را بزنید. صفحهٔ وظیفه باز می‌شود و کار هوش مصنوعی همان‌طور که انجام می‌شود آنجا نمایش داده می‌شود.
| زمینه | آنچه هوش مصنوعی می‌گیرد |
|---|---|
| فایل یا پوشه | مسیری در مخزن، که هوش مصنوعی اول آن را می‌خواند. |
| یادداشت | متنی که جای‌گذاری می‌کنید: یک خطا، یک مشخصات، یک خط لاگ. |
| پیوند | یک نشانی وب، به‌عنوان مرجع. |
| حادثه یا هشدار | وضعیت، توضیح و علت ریشه‌ای آن، همان‌طور که هنگام فرستادن درخواست هستند. |
| استثنا | پیام و رد پشتهٔ آن. |
| مانیتور | نوع، وضعیت و توضیح آن. |
| ترِیس | spanهای آن: نام‌ها، زمان‌ها و خطاهایشان. |
| لاگ‌ها | تازه‌ترین ۲۰ خط لاگ که عبارت جست‌وجوی شما را دارند، از ساعت، روز یا هفتهٔ گذشته. |
| پروفایل کارایی | زمان یک تابع در پروفایل‌های سرویسش کجا می‌رود: چه چیزی آن را فراخوانی می‌کند، خودش چه چیزی را فراخوانی می‌کند و داغ‌ترین خط‌هایش. |
هر درخواست حداکثر ۱۰ مورد زمینه دارد. توکن‌ها، کلیدها، گذرواژه‌ها و نشانی‌های ایمیل در آنچه Status200 می‌خواند، پیش از آنکه هوش مصنوعی آن‌ها را ببیند پوشانده می‌شوند، همان‌طور که در هر جایی که Status200 AI داده‌های شما را می‌خواند.
گفت‌وگوی یک وظیفه
صفحهٔ هر وظیفه یک گفت‌وگو است: آنچه خواسته شد و زمینه‌ای که افزوده شد، سپس نوبت هوش مصنوعی – گام‌هایی که برمی‌دارد، همان‌طور که برمی‌دارد (فایل‌هایی که خواند و ویرایش کرد، آنچه جست‌وجو کرد، دستورهایی که اجرا کرد)، پاسخش، فایل‌هایی که تغییر داد با diff آن‌ها، و درخواست ادغام. بالای صفحه می‌گوید وظیفه کجا کار می‌کند (مخزنش و شاخه‌ای که از آن شروع شد)، چند خط را تغییر داد، با دکمه‌ای به درخواست ادغامش، و وظیفه در چه وضعی است:
| وضعیت | معنای آن |
|---|---|
| در صف | منتظر است تا یک Runner آن را بردارد. |
| در حال کار… | هوش مصنوعی روی آن کار می‌کند. توقف آن را متوقف می‌کند؛ آنچه push کرده روی شاخه می‌ماند. |
| در انتظار شما | هوش مصنوعی پرسشی پرسیده است. در کادر پایین به آن پاسخ دهید. |
| انجام شد | هوش مصنوعی کارش را تمام کرد: پاسخش، و درخواست ادغام اگر کد را تغییر داده باشد. |
| ناموفق | این نوبت نتوانست تمام شود و دلیلش را می‌گوید. تلاش دوباره همان را دوباره می‌خواهد. |
| متوقف‌شده | کسی آن را متوقف کرد. تلاش دوباره همان را دوباره می‌خواهد. |
برای ادامه، در کادر پایین بنویسید که هنگام پیمایش گفت‌وگو در دید می‌ماند: به هوش مصنوعی پاسخ دهید، زمینه بیفزایید یا تغییر بخواهید. هر پاسخ نوبت بعدی همان وظیفه است: تا وقتی درخواست ادغام باز است، روی همان شاخه کار می‌کند و به همان درخواست ادغام push می‌کند. هر وظیفه در هر زمان یک نوبت دارد، پس تا هوش مصنوعی کار می‌کند کادر منتظر می‌ماند. لاگ هر نوبت ثبت کلمه‌به‌کلمهٔ کاری است که در آن انجام شد.
هر کسی که بتواند مخزنی را بخواند، وظایف آن را هم می‌خواند. درخواست از هوش مصنوعی، پاسخ دادن و متوقف کردن یک وظیفه به مجوز ویرایش مخزن نیاز دارد، و دیدن diff یک تغییر هم همین‌طور: بقیه می‌بینند کدام فایل‌ها تغییر کرده‌اند. وظایفی که Status200 خودش شروع می‌کند (پایین‌تر) هم در مخزنشان هستند، به‌صورت گفت‌وگوهایی که می‌توانید در آن‌ها پاسخ دهید.
یک اجرای اصلاح چگونه پیش می‌رود
از یک کلیک تا یک درخواست ادغام
- در کد روی شروع وظیفه کلیک می‌کنید، یا روی یک استثنای حل‌نشده روی رفع با هوش مصنوعی، یا دکمه یا محرک دیگری وظیفه‌ای را شروع می‌کند (وظایف اصلاح از کجا شروع می‌شوند را ببینید).
- وظیفه در صف مخزن خودش قرار می‌گیرد و Runnerی که مخزن انتخاب کرده آن را برمی‌دارد: یکی از Runnerهای شما، یا وقتی هیچ‌کدام را انتخاب نکرده باشد، یک Runner سراسری (ببینید انتخاب Runner مخزن).
- Runner زمینه وظیفه را می‌گیرد. برای یک درخواست، این زمینه واژه‌های آن، زمینهٔ افزوده‌شده و گفت‌وگوی تا این‌جا است؛ برای یک استثنا، نوع، پیام و رد پشته آن.
- مخزن را در فضای کاری خودش کلون می‌کند و یک شاخه می‌سازد. نام اصلاح یک استثنا
oneuptime-fix-exception-است و پس از آن نخستین نویسه‌های شناسه اجرا می‌آید. یک درخواست از شاخه‌ای شروع می‌شود که هنگام پرسیدن انتخاب شد، و درخواست ادغامش به همان شاخه باز می‌شود. یک پاسخ به‌جای آن روی شاخهٔ درخواست ادغام باز وظیفه کار می‌کند. - یک عامل کد که با ارائه‌دهنده LLM پروژه شما کار می‌کند، کد را می‌خواند و تغییر را می‌نویسد. فراخوانی‌های LLM را سرور Status200 انجام می‌دهد، بنابراین Runner هرگز کلید API ارائه‌دهنده شما را ندارد و هر فراخوانی اندازه‌گیری و در لاگ‌های هوش مصنوعی فهرست می‌شود. اصلاح یک استثنا، یک ترِیس کند یا یک حادثه، در حین کار محیط عملیاتی را هم می‌خواند: استثناها، ترِیس‌ها، لاگ‌ها و متریک‌های سرویس‌های مخزن (تله‌متری محیط عملیاتی در یک اصلاح را ببینید).
- روی Runner خودتان، عامل کد پیش از کامیت شدن هر چیزی، تغییرش را همان‌طور که
AGENTS.mdمخزن می‌گوید می‌سازد و تست می‌کند، و آنچه را شکست بخورد ترمیم می‌کند (راستی‌آزمایی پیش از درخواست ادغام را ببینید). - Runner کامیت می‌کند، شاخه را push می‌کند، درخواست ادغام را باز می‌کند (برای یک درخواست، فقط اگر کد را تغییر داده باشد) و فضای کاری را پاک می‌کند.
صفحه‌ای که وظیفه از آن شروع شد، وضعیت زنده آن را نشان می‌دهد. هر وظیفه در مخزن خودش زیر محصولات > کد فهرست شده است: صفحهٔ آن گفت‌وگوی آن است، و لاگ هر نوبت برای هر فایلی که Runner خواند یا نوشت و هر دستوری که اجرا کرد یک خط دارد.
هر اجرا در بودجه‌هایی می‌ماند که سرور اعمال می‌کند: حداکثر ۴۰ فراخوانی LLM و ۱۰۰٬۰۰۰ توکن خروجی. پرس‌وجوهای یک اجرا از تله‌متری محیط عملیاتی هم جزو همان ۴۰ فراخوانی شمرده می‌شوند. اجرایی که به یکی از آن‌ها برسد، به جای چرخیدن در حلقه، با خلاصه‌ای از کار انجام‌شده تا آن لحظه تمام می‌شود. اجراهای اصلاح در محدودیت‌های روزانه هوش مصنوعی پروژه هم شمرده می‌شوند، اگر پروژه آن‌ها را تعیین کرده باشد.
وظایف اصلاح از کجا شروع می‌شوند
| کجا | کلیک | درخواست ادغام |
|---|---|---|
| صفحه AI Assistance یک استثنا | رفع با هوش مصنوعی | باگ پشت استثنا را اصلاح می‌کند. |
| صفحه AI Assistance یک استثنا | Generate Regression Test | تستی اضافه می‌کند که استثنا را بازتولید می‌کند و تا اصلاح باگ شکست می‌خورد. |
| صفحه AI Assistance یک استثنا | بهبود مدیریت خطا | برای خطایی مورد انتظار، مثل ورودی نامعتبر: داده‌های کاربر را از پیام بیرون می‌برد، ورودی را زودتر اعتبارسنجی می‌کند و خطا را رسیدگی‌شده علامت می‌زند، بدون تغییر رفتار. |
| کارت AI Investigation یک حادثه یا هشدار | Open Fix PR from this analysis | علت ریشه‌ای را که بررسی منتشر کرد اصلاح می‌کند (اصلاح خودکار کد از بررسی‌ها را ببینید). |
| ترِیسی که ارزش اصلاح دارد | رفع کارایی با هوش مصنوعی | الگوی کندی را که دکمه نام می‌برد اصلاح می‌کند، مثل یک کوئری N+1 یا فراخوانی‌هایی که می‌توانستند هم‌زمان اجرا شوند. |
| صفحه لاگ‌ها در یک سرویس | بهبود لاگ‌گیری | لاگ‌های سرویس را ساختاریافته، با شدت درست و پیوندخورده به ترِیس‌هایش می‌کند، بدون تغییر رفتار. |
| صفحه ترِیس‌ها در یک سرویس | بهبود ترِیسینگ | هر جا ردیابی سرویس کم است، span و ویژگی اضافه می‌کند، بدون تغییر رفتار. |
| یک تابع در پروفایل‌های کارایی | رفع با هوش مصنوعی | با پروفایل تابع به‌عنوان شاهد، کاری می‌کند که تابع همان کار را با زمان یا حافظهٔ کمتر انجام دهد. |
این دکمه‌ها فقط جایی ظاهر می‌شوند که بتوانند وظیفه‌ای را آغاز کنند. وقتی هوش مصنوعی برای پروژه خاموش است، هیچ‌کدام ظاهر نمی‌شود و منوی کناری یک استثنا AI Assistance ندارد. بهبود لاگ‌گیری و بهبود ترِیسینگ به‌محض اتصال یک مخزن ظاهر می‌شوند، و رفع کارایی با هوش مصنوعی فقط روی ترِیسی که ارزش اصلاح دارد (کاوشگر ترِیس را ببینید). دکمهٔ رفع با هوش مصنوعی یک تابع فقط روی کد خود برنامه نشان داده می‌شود که دست‌کم ۵٪ از زمان یا حافظهٔ پروفایل را می‌گیرد، یا سهمش نسبت به بازه‌ای که با آن مقایسه می‌شود ۳ واحد یا بیشتر رشد کرده است (پروفایل‌گیری پیوسته را ببینید).
برای باز کردن صفحه AI Assistance یک استثنا، استثنا را زیر محصولات > مشاهده‌پذیری > استثناها باز کنید و در منوی کناری آن AI Assistance را انتخاب کنید. استثنای حل‌شده یا بایگانی‌شده را باید اول حل‌نشده علامت بزنید.
Status200 AI خودش هم وظایف اصلاح را شروع می‌کند: از بررسی‌ای که یک تغییر کد پیدا می‌کند، از بررسی‌ای که به دلیل نبود تله‌متری بی‌نتیجه تمام می‌شود، و از AI Insights درباره استثناها و ترِیس‌های کند. هر کدام کلید خودش را دارد؛ اصلاح خودکار کد را ببینید.
تله‌متری محیط عملیاتی در یک اصلاح
Status200 آنچه را کد شما در محیط عملیاتی انجام می‌دهد در اختیار دارد، پس یک اصلاح لازم نیست فقط با یک رد پشته کار کند. عامل کد در حین کار می‌تواند تله‌متری محیط عملیاتیِ سرویس‌هایی را پرس‌وجو کند که این مخزن به آن‌ها تعلق دارد:
| آنچه می‌خواند | برای چه |
|---|---|
| استثناها | گروه‌های استثنایی که در فایل‌های مشخص یا یک تابع پرتاب شده‌اند: چند بار در روزهای اخیر، از کدام نسخهٔ انتشار، و ترِیس یک رخداد اخیر. |
| ترِیس‌ها | پروفایل تأخیر و خطای یک نقطهٔ پایانی یا عملیات، و spanهای یک ترِیس. |
| لاگ‌ها | خط‌های لاگ یک سرویس، بر اساس زمان، شدت، متن یا ترِیس. |
| متریک‌ها | متریکی که یک سرویس گزارش می‌کند، در طول زمان؛ بدون نام، متریک‌هایی که گزارش می‌کند. |
| حوادث | حوادثی که بر سرویس‌ها اثر گذاشته‌اند، یا یک اصلاح Status200 در این مخزن برایشان باز شده است، همراه با علت ریشه‌ای و گزارش پس از حادثهٔ آن‌ها. |
| استقرارها | استقرارهای اخیر و دیگر تغییرهای سرویس‌ها، هر کدام با حکم Status200 دربارهٔ اینکه آیا به سرویس خودش آسیب زده است یا نه. |
| وظیفه | آنچه بررسی می‌کند |
|---|---|
| رفع با هوش مصنوعی روی یک استثنا | اینکه اکنون چند بار پرتاب می‌شود و از کدام نسخهٔ انتشار، لاگ‌ها و ترِیس یکی از رخدادهایش. |
| رفع کارایی با هوش مصنوعی | اینکه عملیات در همهٔ ترِیس‌هایش چقدر پرکار و چقدر کند است، نه فقط در ترِیسی که تحلیل شد. اگر عملیات دیگر کند نباشد، چیزی را تغییر نمی‌دهد. |
| Open Fix PR from this analysis، و اصلاح‌هایی که خودکار از بررسی‌ها باز می‌شوند | استقرارهای پیش از حادثه، خطاها، لاگ‌ها و عملیات‌های کند آن، و اینکه آیا این علت پیش‌تر هم رخ داده است. |
@oneuptime review از GitHub | آنچه محیط عملیاتی دربارهٔ کد تغییرکرده می‌گوید (بازبینی با زمینهٔ محیط عملیاتی را ببینید). |
توضیح درخواست ادغام می‌گوید عامل چه چیزهایی را پرس‌وجو کرد و نتیجه چه نشان داد. وظایف دیگر، مانند تست‌های رگرسیون و بهبود لاگ‌گیری یا ترِیسینگ، محیط عملیاتی را پرس‌وجو نمی‌کنند.
اینکه عامل چه چیزی را می‌تواند بخواند، سرور Status200 از روی خود وظیفه تعیین می‌کند:
- فقط خواندنی. پرس‌وجوها روی سرور Status200 اجرا می‌شوند، هرگز روی Runner، که هیچ اعتبارنامه‌ای برای خواندن تله‌متری ندارد. هیچ کاری که انجام می‌دهند نمی‌تواند پروژهٔ شما را تغییر دهد.
- همین پروژه، و فقط سرویس‌هایی که این مخزن به آن‌ها تعلق دارد. لازم نیست آن‌ها را نگاشت کنید: این‌ها سرویس‌هایی هستند که Status200 این مخزن را برایشان پیدا می‌کند، همان‌طور که مخزن یک اصلاح را پیدا می‌کند - رد پشتهٔ استثناهایشان از فایل‌های آن می‌گذرد، نامی مانند نام آن دارند، یا این مخزن تنها مخزن پروژه است. تله‌متری سرویس دیگری را نمی‌توان خواند.
- بدون حوادث خصوصی، و توکن‌ها، کلیدها، گذرواژه‌ها و نشانی‌های ایمیل پیش از آنکه عامل نتیجه‌ای را ببیند پوشانده می‌شوند، همان‌طور که در هر جایی که Status200 AI داده‌های شما را می‌خواند.
- محدود. حداکثر ۱۲ پرس‌وجو در هر اجرا، که هر کدام جزو ۴۰ فراخوانی اجرا شمرده می‌شود.
وقتی هیچ سرویسی به مخزن نگاشت نشود، وظیفه مانند گذشته بدون تله‌متری محیط عملیاتی اجرا می‌شود.
بازبینی عملیاتی درخواست‌های ادغام
Status200 می‌داند کد شما در محیط عملیاتی چه می‌کند، پس می‌تواند یک درخواست ادغام را با چیزی بازبینی کند که هیچ‌کس با خواندن diff نمی‌بیند. بازبینی Pull Requestها بر اساس محیط عملیاتی را زیر تنظیمات بیشتر در صفحهٔ تنظیمات یک مخزن در کد روشن کنید تا هر درخواست ادغامی که کسی با دسترسی نوشتن باز می‌کند یا به آن push می‌کند، یک دیدگاه بگیرد که می‌گوید محیط عملیاتی دربارهٔ کدی که تغییر می‌دهد چه نشان می‌دهد. این دیدگاه با هر push در همان جا به‌روز می‌شود، و صفحهٔ بازبینی‌های عملیاتی مخزن در کد هر بازبینی را همراه با بازبینی دوباره نگه می‌دارد.
| آنچه می‌خواند | از کدی که درخواست ادغام تغییر می‌دهد |
|---|---|
| استثناها | استثناهایی که در 7 روز گذشته در خط‌ها، تابع‌ها و فایل‌های تغییریافته رخ داده‌اند، با علامت‌گذاری موارد تازه و مدیریت‌نشده. |
| عملیات | عملیات ردیابی‌شده‌ای که در ساعت گذشته کد تغییریافته را اجرا کرده‌اند: spanها، خطاها و p95 آن‌ها. |
| تابع‌های پرهزینه | تابع‌های کد تغییریافته که در ساعت گذشته سهمی از پروفایل‌های سرویس‌ها دارند. |
| حوادث | حوادث 30 روز گذشتهٔ سرویس‌ها که هنوز باز هستند، یا علت ریشه‌ای یا گزارش پس از حادثهٔ آن‌ها به کد تغییریافته اشاره می‌کند. هرگز یک حادثهٔ خصوصی. |
| استقرارها | استقرارهای 7 روز گذشتهٔ سرویس‌ها که Status200 به افت کارایی در آن‌ها مشکوک است. |
وقتی محیط عملیاتی چیزی نشان می‌دهد، Status200 AI آن را کنار diff می‌خواند و نکته‌هایی که باید زیر نظر داشت را اضافه می‌کند: چند نکتهٔ کوتاه که هر کدام بر پایهٔ واقعیت‌هاست. این کار فقط تا وقتی هوش مصنوعی برای پروژه روشن است اجرا می‌شود، حداکثر 10 بار در روز برای یک درخواست ادغام و 100 بار برای یک مخزن، و مثل هر فراخوانی هوش مصنوعی شمرده می‌شود؛ واقعیت‌ها هر بار بدون آن خوانده می‌شوند. وقتی محیط عملیاتی چیزی دربارهٔ تغییر نشان ندهد، Status200 چیزی منتشر نمی‌کند.
- فقط آمار کلی. دیدگاه فقط شمارش‌ها، مدت‌زمان‌ها و نام کدها را دارد: هرگز پیام یک استثنا، خطی از لاگ، عنوان یک حادثه یا داده‌های شخصی.
- مخزن‌های عمومی یک پیوند می‌گیرند. هر کسی می‌تواند درخواست‌های ادغام یک مخزن عمومی را بخواند، پس آنجا دیدگاه فقط به بازبینی در Status200 پیوند می‌دهد که فقط اعضای پروژه می‌توانند بازش کنند. دیدگاه بازبینی عملیاتی زیر تنظیمات بیشتر در صفحهٔ تنظیمات مخزن می‌تواند همه جا فقط پیوندی به بازبینی را منتشر کند، یا خود بازبینی، حتی در مخزن عمومی را.
- مشارکت‌کنندگان بیرونی نمی‌توانند آن را شروع کنند. یک درخواست ادغام فقط وقتی خودبه‌خود بازبینی می‌شود که نویسنده‌اش، و هر کسی که به آن push کرده، بتوانند در مخزن بنویسند. درخواست هر کس دیگر - یک مشارکت‌کنندهٔ بیرونی، یک fork، یک بات - وقتی بازبینی می‌شود که کسی با دسترسی نوشتن روی آن
@oneuptime production reviewرا بنویسد، یا در کد روی بازبینی دوباره بزند. - فقط خواندنی. بازبینی چیزی را کلون نمی‌کند و چیزی از درخواست ادغام را اجرا نمی‌کند. diff و عنوان آن برای Status200 AI داده هستند، هرگز دستور نیستند: هوش مصنوعی هیچ ابزاری ندارد، و آنچه می‌نویسد به‌صورت متن در دیدگاه قرار می‌گیرد.
این کلید برای مخزن‌هایی که GitHub App از این به بعد متصل می‌کند روشن است. مخزنی که پیش از پیدایش آن متصل شده، آن را خاموش نگه می‌دارد تا وقتی خودتان روشنش کنید.
راستی‌آزمایی پیش از درخواست ادغام
یک مخزن در یک AGENTS.md در ریشه‌اش، فایلی که عامل‌های کدنویسی می‌خوانند، می‌گوید چگونه ساخته و تست می‌شود. عامل کد پیش از آنکه چیزی را تغییر دهد، AGENTS.md مخزن (یا CLAUDE.md آن، وقتی AGENTS.md ندارد) را از شاخه‌ای که وظیفه از آن شروع می‌شود می‌خواند و همان‌طور که می‌گوید کار می‌کند. اگر هیچ‌کدام نباشد، روش کار را از CONTRIBUTING.md مخزن، README، اسکریپت‌های بسته، Makefile یا گردش‌کارهای CI یاد می‌گیرد. در Status200 چیزی برای راه‌اندازی نیست.
| جایی که هوش مصنوعی کار می‌کند | کاری که با ساخت و تست‌های مخزن می‌کند |
|---|---|
| یکی از Runnerهای شما | تغییرش را پیش از باز شدن درخواست ادغام می‌سازد و تست می‌کند، آنچه را شکست بخورد اصلاح می‌کند و دوباره بررسی می‌کند، و در خلاصه‌اش می‌گوید کدام بررسی‌ها را اجرا کرده است. هر دستوری که اجرا می‌کند حداکثر ۲ دقیقه وقت دارد، بدون اعتبارنامه‌های خود Runner در محیطش. |
| Runner سراسری | هیچ دستوری اجرا نمی‌کند: تغییر را می‌نویسد و درخواست ادغام را باز می‌کند، و CI خود مخزن شما آن را بررسی می‌کند. |
هیچ چیزی از درخواست ادغامی که از یک fork می‌آید هرگز به‌عنوان دستورالعمل‌های مخزن خوانده نمی‌شود: بازنگری چنین درخواست ادغامی را رد می‌کند، و بازبینی شاخهٔ پایه را می‌خواند.
دستورهای تعیین‌شده روی یک مخزن
کد دیگر دستورهای راه‌اندازی، ساخت و تست را نمی‌پرسد، اما مخزنی که آن‌ها را دارد، چه از قبل و چه از طریق API یا Terraform تعیین شده باشند، نگهشان می‌دارد. آن‌ها به‌صورت فقط‌خواندنی روی کارت فرمان‌های ساخت و آزمون، زیر تنظیمات بیشتر در صفحه تنظیمات مخزن نشان داده می‌شوند، و حذف فرمان‌ها هر سه را حذف می‌کند. تا وقتی یکی از آن‌ها تعیین شده باشد، هر اجرای اصلاح روی Runner خودتان پیش از باز شدن درخواست ادغام، تغییر خود را با آن‌ها هم بررسی می‌کند:
- وقتی کار عامل کد تمام می‌شود، دستورها به ترتیب در ریشه مخزن، روی Runner، در فضای کاری کلون‌شده اجرا می‌شوند. هر کدام تا ۱۵ دقیقه وقت دارد و با
CI=trueاجرا می‌شود تا هیچ چیز منتظر ورودی نماند؛ نخستین شکست، دور را متوقف می‌کند. - در صورت شکست، انتهای خروجی دستورِ شکست‌خورده به‌عنوان یک وظیفه ترمیم به همان عامل کد برمی‌گردد، با این دستور که به جای تضعیف یا رد کردن تست‌ها، تغییر خودش را درست کند، و دستورها دوباره اجرا می‌شوند. حداکثر ۲ بار برای ترمیم تلاش می‌کند. این تلاش‌ها بودجه LLM اجرا را به اشتراک می‌گذارند و ویرایش‌هایشان در همان کامیتِ اصلاح قرار می‌گیرد.
- نتیجه، یعنی موفق، ناموفق یا ردشده (بدون دستور تعیین‌شده، یا یک Runner سراسری)، در بخش Verification توضیح درخواست ادغام نوشته و روی درخواست ادغام وظیفه ثبت می‌شود.
تغییری که هنوز در راستی‌آزمایی رد می‌شود دور انداخته نمی‌شود: درخواست ادغام به هر حال باز می‌شود، با بخش "Verification failed" که به‌وضوح علامت خورده، نام دستور شکست‌خورده را می‌آورد و با خروجی آن تمام می‌شود. کار حفظ می‌شود و بازبین تصمیم می‌گیرد. مخزنی که هیچ دستوری برایش تعیین نشده، به جای القای یک ساخت سبز، ردشده گزارش می‌شود.
دستورها تنظیمات مخزن هستند که تیم شما می‌نویسد و روی Runner خودتان اجرا می‌شوند: همان مدل اعتماد گام‌های Bash یک رانبوک. هوش مصنوعی هرگز آن‌ها را نمی‌نویسد یا تغییر نمی‌دهد. Runner سراسری، که Status200 برای همه پروژه‌ها اجرا می‌کند، هرگز آن‌ها را اجرا نمی‌کند: روی یک Runner سراسری، اصلاح نوشته و برای بازبینی باز می‌شود، راستی‌آزمایی ردشده گزارش می‌شود و CI خود مخزن شما تغییر را بررسی می‌کند. برای اینکه اصلاح‌ها پیش از باز شدن درخواست ادغام ساخته و تست شوند، یک Runner از آن خودتان اجرا کنید.
پس از ادغام یک اصلاح
ادغام یک اصلاح تا اجرا نشود چیزی را برطرف نمی‌کند. همین که یک Pull Request اصلاحی ادغام شود، Status200 منتظر استقرار ثبت‌شده‌ای می‌ماند که آن را در خود داشته باشد (ببینید استقرارها و تغییرها) و در آن استقرار آنچه را اصلاح برایش بود زیر نظر می‌گیرد. Pull Request وظیفه در Code می‌گوید نتیجه چه شد، و صفحه AI Assistance استثنا، گزارش‌های هوش مصنوعی حادثه و بینش هوش مصنوعی‌ای که اصلاح از آن آمد نیز می‌گویند:
| اصلاحِ | آنچه زیر نظر است | جواب داد | جواب نداد |
|---|---|---|---|
| یک استثنا | اینکه استثنا دوباره رخ دهد | در محیط عملیاتی برطرف شد | پس از اصلاح همچنان رخ می‌دهد |
| یک ردیابی کند یا بینش تأخیر | p99 عملیاتی که اصلاح نام می‌برد | در محیط عملیاتی سریع‌تر شد | پس از اصلاح همچنان کند است |
| علت ریشه‌ای یک حادثه یا هشدار | اینکه مانیتور آن مورد دیگری برانگیزد | در محیط عملیاتی برطرف شد | پس از اصلاح دوباره رخ داد |
| تله‌متری، لاگ‌گیری یا ردیابی گم‌شده | آنچه اصلاح می‌افزاید، و باقی تله‌متری سرویس | در محیط عملیاتی دریافت می‌شود | پس از اصلاح تله‌متری متوقف شد |
تا وقتی استقراری آن را نرسانده، اصلاح ادغام‌شده، در انتظار استقرار نشان می‌دهد و در مدتی که زیر نظر است مستقرشده، در حال پایش در محیط عملیاتی. اصلاحی که هیچ استقرار ثبت‌شده‌ای تا ۱۴ روز آن را در خود نداشته باشد، یا محیط عملیاتی نتواند درباره‌اش چیزی بگوید، در محیط عملیاتی راستی‌آزمایی نشد نشان می‌دهد. قواعد در اصلاح خودکار کد آمده است. آزمون رگرسیون، رسیدگی بهتر به خطا، بازبینی و درخواست در Code زیر نظر گرفته نمی‌شوند: محیط عملیاتی نمی‌تواند نشان دهد آن‌ها چه چیزی را تغییر می‌دهند.
پیش از شروع
یک وظیفه به سه چیز نیاز دارد. کادر درخواست کد و صفحه AI Assistance استثنا پیش از پیشنهاد شروع، هر سه را بررسی می‌کنند و می‌گویند چه چیزی کم است.
| چه | Status200 Cloud | خودمیزبان |
|---|---|---|
| یک ارائه‌دهنده LLM | چیزی برای راه‌اندازی نیست: پروژه‌ای که ارائه‌دهنده خودش را ندارد از ارائه‌دهنده سراسری استفاده می‌کند که هزینه‌اش از اعتبار هوش مصنوعی پروژه پرداخت می‌شود. ارائه‌دهنده خودتان، زیر تنظیمات پروژه > هوش مصنوعی > ارائه‌دهندگان LLM، مقدم است. | متغیرهای محیطی GLOBAL_LLM_PROVIDER_* را یک بار روی سرور تعیین کنید، یا یک ارائه‌دهنده به پروژه اضافه کنید. |
| مخزنی که از طریق GitHub App متصل شده | محصولات > کد، سپس اتصال GitHub. اگر اپ از پیش روی حساب GitHub نصب شده است، به‌جای آن روی اتصال یک نصب موجود کلیک کنید: نصب دوباره آن را متصل نمی‌کند. به طرح Growth نیاز دارد. | همین، وقتی نمونه شما یک GitHub App داشته باشد (یکپارچه‌سازی GitHub را ببینید). |
| یک Runner که اصلاح کد با هوش مصنوعی را اجرا می‌کند | چیزی برای اجرا نیست: مخزنی که هیچ Runnerی انتخاب نکند، روی Runnerهای سراسری Status200 کار می‌کند. | سرویس runner در Docker Compose، یا Runner چارت Helm (runner.enabled، به‌طور پیش‌فرض روشن)، خودش را ثبت می‌کند و در هر مخزنی که Runnerی انتخاب نکند اصلاح کد با هوش مصنوعی را اجرا می‌کند. |
روی یک نمونه خودمیزبان، ارائه‌دهنده سراسری یک بلوک از config.env (Docker Compose) یا مقادیر Helm شماست. برای یک Ollama خودمیزبان:
GLOBAL_LLM_PROVIDER_TYPE=Ollama
# An address the Status200 server can reach, never localhost.
GLOBAL_LLM_PROVIDER_BASE_URL=http://ollama:11434
GLOBAL_LLM_PROVIDER_MODEL_NAME=llama3.1
# No GLOBAL_LLM_PROVIDER_API_KEY needed — Ollama is keyless.هر ارائه‌دهنده پشتیبانی‌شده‌ای کار می‌کند: برای همه آن‌ها و هر متغیر محیطی، ارائه‌دهندگان LLM را ببینید.
لازم نیست مخزن‌ها را به سرویس‌ها نگاشت کنید. وقتی وظیفه‌ای شروع می‌شود، Status200 مخزن را با تطبیق مسیرهای فایل در رد پشته استثنا با مخزن‌های متصل شما پیدا می‌کند. اگر هیچ‌کدام مطابقت نداشته باشد، به مخزنی با نامی مانند نام سرویس برمی‌گردد و سپس، اگر پروژه فقط یک مخزن داشته باشد، به همان مخزن. صفحه AI Assistance نشان می‌دهد کدام مخزن را پیدا کرده است.
انتخاب Runner مخزن
هر مخزن Runnerی را انتخاب می‌کند که هوش مصنوعی روی آن در مخزن کار می‌کند: در صفحه تنظیمات آن در کد، تنظیمات بیشتر را باز کنید، روی ویرایش در کارت Runner کلیک کنید و یکی را انتخاب کنید. مخزنی که GitHub App وارد می‌کند، اگر پروژه Runner پیش‌فرض داشته باشد، روی آن شروع می‌کند. مخزنی که هیچ‌کدام را انتخاب نکند، روی Runner سراسری کار می‌کند که Status200 برای همه پروژه‌ها اجرا می‌کند.
| Runner | با یک وظیفه چه می‌کند |
|---|---|
| Runner سراسری | تغییر را می‌نویسد و درخواست ادغام را باز می‌کند، بی‌آنکه آن را بسازد یا تست کند: CI خود مخزن شما تغییر را بررسی می‌کند. |
| یکی از Runnerهای شما | تغییر را همچنین همان‌طور که AGENTS.md مخزن می‌گوید، روی میزبانی که در اختیار شماست، می‌سازد و تست می‌کند. |
فقط Runnerی که یک مخزن انتخاب کرده وظیفه‌های آن و یک توکن برای آن را می‌گیرد. در پروژه‌ای که استفاده از Runnerهای سراسری را زیر رانبوک‌ها > Runnerها خاموش کند، هر مخزن به یکی از Runnerهای خود پروژه نیاز دارد. صفحه هر Runner مخزن‌هایی را که آن را انتخاب کرده‌اند فهرست می‌کند.
اجرای یک Runner از آن خودتان
برای اجرای یک Runner در جای دیگر، مثلاً روی ماشینی نزدیک به مخزن‌هایتان:
Runner را بسازید
یک Runner زیر رانبوک‌ها > Runnerها بسازید و در ردیف آن روی نمایش دستورالعمل‌های راه‌اندازی کلیک کنید. این دستور کلید مخفی Runner را در خود دارد که فقط Project Owner، Project Admin یا Runbook Admin می‌تواند آن را بخواند. چیزی شبیه این است:
docker run --name status200-runner --restart unless-stopped \ -e STATUS200_RUNNER_ID=<runner-id> \ -e STATUS200_RUNNER_KEY=<runner-key> \ -e STATUS200_URL=<your-status200-url> \ -d status200/runner:releaseآن را برای مخزن انتخاب کنید
در صفحه تنظیمات مخزن در کد، تنظیمات بیشتر را باز کنید، روی ویرایش در کارت Runner کلیک کنید و آن Runner را انتخاب کنید. Runner تغییر را با heartbeat بعدی‌اش، در حدود یک دقیقه، می‌گیرد؛ نیازی به راه‌اندازی دوباره نیست.
بررسی کنید که وصل می‌شود
Runner ظرف یکی دو دقیقه در صفحه رانبوک‌ها > Runnerها متصل نشان داده می‌شود. اگر نشد، لاگ کانتینر (
docker logs status200-runner) را برای خطای اعتبارنامه یا شبکه بخوانید.
هر روشی برای اجرای کانتینر کار می‌کند (Docker Compose، Kubernetes و مانند آن)، به شرطی که این متغیرها را داشته باشد و از طریق HTTPS به نمونه Status200 شما برسد:
| متغیر | چیست |
|---|---|
STATUS200_RUNNER_ID | شناسه Runner، از داشبورد. |
STATUS200_RUNNER_KEY | کلید مخفی Runner. |
STATUS200_URL | نشانی نمونه Status200 شما (https://status200.ru در Status200 Cloud). |
پیش از Status200 12، اصلاح کد با هوش مصنوعی روی یک مؤلفه جداگانه AI Agent اجرا می‌شد (ایمیج status200/ai-agent با متغیرهای AI_AGENT_*). این مؤلفه در Runner ادغام شده است: اگر هنوز یکی را اجرا می‌کنید، راهنمای ارتقای v11 به v12 می‌گوید چگونه آن را جایگزین کنید.
اصلاح خودکار کد از بررسی‌ها
وقتی یک بررسی هوش مصنوعی تحلیل علت ریشه‌ای را روی یک حادثه یا هشدار منتشر می‌کند و طبقه‌بندی دقیق آن تغییری در کد را توصیه می‌کند، کارت بررسی Open Fix PR from this analysis را پیشنهاد می‌دهد: یک وظیفه اصلاح که کل زمینه‌اش همان تحلیل منتشرشده است. این دکمه وقتی پنهان است که راه‌حل عملیاتی، فقط مربوط به زیرساخت، بیرونی، یک رد مورد انتظار، خطای کاربر یا بی‌نتیجه باشد. تا وقتی اصلاح خودکار حوادث تازه در حوادث > هوش مصنوعی > تنظیمات روشن است (و اصلاح خودکار هشدارهای تازه در هشدارها > هوش مصنوعی > تنظیمات)، اصلاح‌های واجد شرایط بدون کلیک انجام می‌شوند. اصلاح در آغاز خاموش است، برای پروژه‌های تازه هم. بدون قاعدهٔ هوش مصنوعی، هر اصلاح واجد شرایط باز می‌شود؛ با قواعد فقط برای موردی که با یک قاعده مطابقت دارد، وقتی pull requestهای اصلاح در آن قاعده روشن باشد (در قاعدهٔ تازه روشن است)، و فقط در مخازن کدی که آن قاعده نام می‌برد.
تا وقتی اصلاح روشن است، بررسی‌ای که با یک علت ریشه‌ای مطمئن و مستند پایان می‌یابد که یک تغییر کد می‌تواند آن را اصلاح کند، همان وظیفه اصلاحی را در صف می‌گذارد که دکمه می‌سازد. این تصمیم یک طبقه‌بندی محدود است که سرور آن را بررسی می‌کند، نه الگویی که با متن تحلیل تطبیق داده شود: فقط یک حکم مثبت برای اصلاح کد، درخواست ادغام باز می‌کند. نبود شواهد، راه‌حلی بیرون از کد و طبقه‌بندی ناموفق، همگی به انجام ندادن هیچ کاری ختم می‌شوند.
همه چیزهای دیگر مثل دکمه است:
- درخواست ادغام آماده بازبینی باز می‌شود، بر پایه تحلیل منتشرشده نوشته می‌شود و به مخزنی متصل از طریق GitHub App (اگر قواعد مطابق مخزنی نام ببرند، یکی از همان‌ها) و یک Runner آنلاین برای کار در آن نیاز دارد: همان که مخزن انتخاب کرده، یا یک Runner سراسری.
- در محدودیت روزانه وظایف اصلاح آن سیگنال (Daily Incident AI Fix Task Limit یا Daily Alert AI Fix Task Limit، زیر تنظیمات بیشتر در صفحه تنظیمات هوش مصنوعی آن) و در سقف درخواست‌های ادغام باز مخزن شمرده می‌شود، اگر هر کدام تعیین شده باشد. اگر تعیین نشده باشند، هیچ‌کدام چیزی را محدود نمی‌کند.
- هر محرک اول به دنبال وظیفه اصلاحی می‌گردد که برای همان حادثه یا هشدار از قبل در صف است یا در حال اجراست، بنابراین یک محرک خودکار و یک کلیک معمولاً یک وظیفه می‌شوند، نه دو درخواست ادغام. این بررسی یک خواندن پیش از نوشتن است، نه یک قفل، پس دو محرک در دقیقاً همان لحظه هنوز ممکن است هر دو عبور کنند.
- اجرا را سیستم می‌نویسد، به نام کسی ثبت نمی‌شود و هیچ چیز خودبه‌خود ادغام نمی‌شود.
وقتی اصلاح شکست می‌خورد
اجرا خطا می‌دهد
اصلاح اعمال نشد، مخزن یا شاخه‌ای که درخواست از آن شروع شد در دسترس نبود یا فراخوانی LLM شکست خورد. گفت‌وگوی وظیفه، و صفحه‌ای که وظیفه از آن شروع شد، دلیل را نشان می‌دهند و تلاش دوباره را پیشنهاد می‌کنند. لاگ آن نوبت، لاگ کامل اجرا را دارد.
Runner در میانه یک اجرا متوقف می‌شود
اجرایی که heartbeat آن بیش از ۱۲ دقیقه خاموش مانده، با خطا ناموفق می‌شود. هرگز خودبه‌خود دوباره در صف قرار نمی‌گیرد، چون ممکن است Runner بخشی از یک شاخه اصلاح را پیش‌تر push کرده باشد؛ آن را دوباره از همان جایی شروع کنید که شروعش کردید.
هیچ Runnerی وظیفه را برنمی‌دارد
وظیفه‌ای که بیش از ۳۰ دقیقه منتظر بماند در حالی که Runnerی که باید آن را بردارد متصل نیست - همان که مخزنش انتخاب کرده، یا یک Runner سراسری برای مخزنی که هیچ‌کدام را انتخاب نکرده - با پیامی که می‌گوید کدام، شکست می‌خورد، تا هرگز برای همیشه در حال اجرا نشان داده نشود. وقتی یک Runner آنلاین ولی مشغول است، وظایف در صف منتظر نوبت خود می‌مانند. Runnerی که از کد قدیمی‌تر است هرگز درخواستی از کد نمی‌گیرد: Runnerی را که خودتان اجرا می‌کنید همراه با سرور به‌روز کنید.
حریم خصوصی
کلون مخزن شما در یک فضای کاری درون کانتینر Runner قرار دارد و وقتی اجرا تمام شود، چه موفق چه ناموفق، پاک می‌شود. Runner هرگز کلید API ارائه‌دهنده LLM شما را ندارد: سرور Status200 فراخوانی‌های LLM را برای آن انجام می‌دهد و پرس‌وجوهای تله‌متری محیط عملیاتی را هم اجرا می‌کند. Status200 مخزن شما را نگه نمی‌دارد و روی کد شما آموزش نمی‌بیند. لاگ وظیفه ۳۰۰ نویسه نخست خروجی هر گام را نگه می‌دارد تا بتوانید ببینید Runner چه کرد، و این می‌تواند تکه‌هایی از کد را در بر بگیرد. یک Runner خودمیزبان را با ارائه‌دهنده LLM خودتان (از جمله Ollama محلی) اجرا کنید تا کد شما هرگز زیرساختتان را ترک نکند.
در نقشه راه
برنامه‌ریزی‌شده و امروز در دسترس نیست:
- پشتیبانی از GitLab. مخزن‌ها فقط از طریق GitHub App متصل می‌شوند.