Smart Retry جنکینز: فقط خطاهایی که ارزش داره رو دوباره امتحان کن
خلاصهٔ کاملتر
به گفتهٔ نویسنده، تو خیلی از محیطهای جنکینز شکست یه بیلد لزوماً معنیش این نیست که کد خرابه. گاهی یه agent روی کوبرنتیز evict میشه، یه git fetch وسط کار قطع میشه، یا مخزن artifact یه قطعی کوتاه داره؛ تو همهٔ اینها یه rebuild دستی معمولاً موفق میشه. پلاگین smartRetry دقیقاً برای همین جور خطاهای گذرا ساخته شده، بدون اینکه هر step شکستخورده رو خودکار دوباره اجرا کنه.
ایدهٔ اصلی سادهست: اول دستهبندی، بعد تلاش دوباره. وقتی بلاکی که داخل smartRetry پیچیده شده fail میشه، پلاگین اول خطا و یه تیکه از خروجی کنسول رو میگیره، بعد اون رو تو یه دستهٔ مشخص مثل AGENT_LOST، SCM_TRANSIENT، NETWORK_TRANSIENT، COMPILATION_FAILURE یا UNKNOWN جا میده، بعد چک میکنه که آیا اون دسته زیر پروفایل فعال قابلretry هست یا نه، و فقط اونوقت یه تلاش دیگه زمانبندی میکنه.
استفادهٔ پایهایش هم همینه؛ یه بلاک idempotent رو داخلش میپیچی و پروفایل و تعداد تلاش و نوع backoff رو مشخص میکنی:
smartRetry(profile: 'infra', maxRetries: 2, backoff: 'exponential') {
sh 'mvn -B verify'
}نویسنده میگه پلاگین عمداً محافظهکار طراحی شده. دو تا پروفایل داخلی داره: conservative که فقط AGENT_LOST و SCM_TRANSIENT رو دوباره امتحان میکنه، و infra که علاوه بر اونها، خطاهای شبکه و مخزن artifact و ارائهدهندهٔ هویت رو هم پوشش میده. اگه اولین باره که retry خودکار رو به تیم اضافه میکنی، conservative امنترین نقطهٔ شروعه.
یه بخش مهم دیگهاش شفافیته. وقتی بیلد fail میشه، پلاگین فقط نمیگه «دارم دوباره امتحان میکنم»؛ دستهبندی، تصمیم و دلیلش رو لاگ میکنه و هر بیلد یه صفحهٔ اختصاصی Smart Retry میگیره که نشون میده کدوم قانون با خطا مطابقت داشته و بیلد بالاخره recover شده یا متوقف. اینجوری راحت میشه جواب داد که «چرا این بیلد retry شد؟».
نویسنده تأکید میکنه که smartRetry قصد نداره جنکینز رو به سیستمی تبدیل کنه که همهچی رو حدس بزنه؛ بهطور پیشفرض روی UNKNOWN، خطاهای کامپایل، خطاهای منطقی اسکریپت و abort کاربر دوباره تلاش نمیکنه. این کمتر جاهطلبانه بهنظر میرسه، ولی برای CI واقعی که امنیت و پیشبینیپذیری مهمه معمولاً انتخاب بهتریه. پروژه هم روی گیتهاب متنبازه.
نکات کلیدی:
- smartRetry یه step پایپلاین جنکینزه که اول خطا رو دستهبندی میکنه و فقط خطاهای گذرای زیرساختی رو دوباره اجرا میکنه.
- دو پروفایل آماده داره: conservative (محدود) و infra (گستردهتر)؛ برای شروع conservative امنتره.
- هر تصمیم retry بهصورت شفاف لاگ میشه و هر بیلد یه صفحهٔ گزارش اختصاصی داره.
- بهطور پیشفرض روی خطاهای کامپایل، خطاهای منطقی و abort کاربر تلاش دوباره نمیکنه.
- بهترین کاربردش دور بلاکهای کوچیک و idempotent مثل checkout یا دانلود وابستگیهاست.




