تحلیل خطای GitLab CI/CD با AI Agent و MCP

وقتی Pipeline در GitLab قرمز می‌شود، برنامه‌نویس باید بفهمد کدام Job شکست خورده، خطای اصلی کجای لاگ است و از کجا باید بررسی را شروع کند. یک AI Agent متصل به GitLab MCP می‌تواند این بررسی را انجام دهد و نتیجه را همراه با خط شاهد و لینک Job در همان Merge Request گزارش کند.

فرض کنید Job تست سرویس پرداخت شکست خورده است. عامل ابتدا Job ناموفق را پیدا می‌کند و لاگ آن را می‌خواند. اگر لاگ نشان دهد تست احراز هویت به‌جای 401 پاسخ 200 گرفته، عامل همین اختلاف را گزارش می‌کند و در صورت نیاز تغییرات Merge Request را می‌خواند.

Webhook و MCP هرکدام چه کاری انجام می‌دهند؟

Webhook بررسی را شروع می‌کند. GitLab با تغییر وضعیت Pipeline رویدادی می‌فرستد. سرویس دریافت‌کننده اصالت درخواست را بررسی می‌کند و اگر وضعیت failed باشد، شناسهٔ پروژه و Pipeline را در صف پردازش قرار می‌دهد. مستندات رویدادهای Webhook

MCP ابزارهای GitLab را در اختیار عامل می‌گذارد. برنامهٔ اجراکنندهٔ عامل به‌عنوان کلاینت MCP به GitLab وصل می‌شود. عامل ابتدا اطلاعات Pipeline را می‌گیرد و بر اساس نتیجه، لاگ Job یا تغییرات Merge Request را درخواست می‌کند. مستندات ابزارهای GitLab MCP

۱. عامل را به سرور MCP گیت‌لب وصل کنید

در کلاینت عامل اتصال HTTP به https://gitlab.com/api/v4/mcp را تعریف کنید. برای GitLab سازمانی، دامنهٔ نمونهٔ خودتان را جایگزین کنید و احراز هویت را مطابق مستندات همان نسخه تنظیم کنید. مجموعهٔ ابزار ci را برای بررسی Pipeline و Job در دسترس قرار دهید. برای خواندن تغییرات MR، ابزار خواندن مربوط به merge_requests را اضافه کنید. راهنمای اتصال GitLab MCP

فهرست ابزارهای اتصال را بررسی کنید. در این مثال از get_pipeline و get_job استفاده می‌کنیم. نسخه‌های قدیمی‌تر ممکن است ابزارهای get_pipeline_jobs و get_job_log را ارائه کنند. نام و ورودی ابزارها را با نسخهٔ نصب‌شده تطبیق دهید.

۲. به عامل بگویید کدام Pipeline را بررسی کند

پس از دریافت Webhook، سرویس به عامل می‌گوید Pipeline شمارهٔ 981 از پروژهٔ 42 را بررسی کند و برای هر Job ناموفق، دلیل قابل مشاهده، خط شاهد و قدم بعدی را بنویسد. شناسهٔ Job از نتیجهٔ فراخوانی اول به دست می‌آید. مستندات ابزارهای Pipeline و Job

get_pipeline({ "id": "42", "pipeline_id": 981, "include": ["jobs"] })
get_job({ "id": "42", "job_id": 7412, "include": ["log"] })

اگر چند Job شکست خورده‌اند، شواهد هرکدام را جدا نگه دارید. ممکن است تست واحد به‌دلیل تغییر رفتار برنامه شکست بخورد و Job دیگری به‌خاطر مشکل Runner حتی به اجرای تست نرسد. اگر لاگ ناقص است، گزارش باید اطلاعات موجود و دادهٔ لازم برای ادامهٔ بررسی را مشخص کند.

۳. دلیل شکست را از روی لاگ استخراج کنید

فرض کنید Job unit-tests این لاگ را برگردانده است.

$ pytest tests/test_checkout.py -q
FAILED tests/test_checkout.py::test_checkout_requires_auth
E   assert 200 == 401
E    +  where 200 = response.status_code
1 failed, 37 passed
ERROR: Job failed: exit code 1

خط آخر وضعیت اجرا را نشان می‌دهد. نام تست و خط assert 200 == 401 شواهد لازم برای شروع بررسی را فراهم می‌کنند. عامل می‌تواند چنین گزارشی بنویسد.

Job ناموفق unit-tests در Pipeline شمارهٔ 981، شناسهٔ Job برابر 7412.

دلیل شکست تست test_checkout_requires_auth انتظار پاسخ 401 داشت، اما 200 دریافت کرد و pytest با خطا خارج شد.

قدم بعدی بررسی کنید درخواست تست واقعاً بدون احراز هویت ارسال شده باشد. سپس تغییرات مسیر پرداخت، middleware احراز هویت و fixture کاربر را مرور کنید.

شواهد فایل tests/test_checkout.py و خط assert 200 == 401.

اگر عامل به تغییرات MR دسترسی داشته باشد، می‌تواند بررسی کند آیا کد احراز هویت یا fixture تست در همان تغییر دست‌کاری شده است. تا وقتی شواهد کافی ندارد، احتمال وجود مشکل در کد احراز هویت را به‌عنوان فرضیه گزارش می‌کند.

۴. گزارش را در همان Merge Request ثبت کنید

سرویس، MR مرتبط را با داده‌های GitLab مشخص می‌کند و لینک واقعی Pipeline و Job را به گزارش اضافه می‌کند. عامل گزارش را می‌نویسد و سرویس آن را ثبت می‌کند تا مقصد کامنت و دسترسی نوشتن در کد سرویس کنترل شوند. اگر MR مرتبط مشخص نبود، گزارش را در صف داخلی بررسی نگه دارید. برای ارسال مجدد Webhook یا شکست دوباره پس از Retry، شناسهٔ گزارش قبلی را نگه دارید تا همان کامنت به‌روزرسانی شود. Pipelines API · Notes API

دسترسی عامل را به ابزارهای خواندن موردنیاز محدود کنید و داده‌های حساس را قبل از رسیدن لاگ به مدل حذف کنید. متن لاگ را به‌عنوان دادهٔ ورودی تحلیل کنید. برای آزمایش اولیه، یک شکست تست، یک مشکل Runner و یک Job با لاگ ناقص را بازپخش کنید. بررسی کنید که هر گزارش به Job درست لینک بدهد، خط شاهد را بیاورد و میزان قطعیتش با شواهد هم‌خوان باشد. ملاحظات امنیتی GitLab MCP

مقالهٔ نقش AI Agentها در دواپس

مشاهدهٔ خدمات دواپس ایران