اعمل Stale PR Reminder Bot على GitHub: ذكّر الفريق بـ 50 سطر بصفر تكلفة

الخطوات بالتفصيل

الخطوة 1: حضّر Slack Incoming Webhook

افتح api.slack.com/apps، اعمل New App بصيغة "From scratch"، اختار workspace، فعّل Incoming Webhooks، واختار القناة (يفضّل قناة منفصلة زي #pr-review). هتاخد URL بالشكل https://hooks.slack.com/services/T.../B.../.... الـ URL ده بياخد POST بـ JSON ويعرض الرسالة في القناة فوراً، بدون أي مكتبة Slack.

الخطوة 2: حط الـ URL في GitHub Secrets

روح Settings > Secrets and variables > Actions في الريبو، اعمل secret جديد اسمه SLACK_WEBHOOK_URL ولصق فيه القيمة. ممنوع تلصقها في الكود مباشرة، لأن أي fork للريبو هيكشفها فوراً، وأي bot كاشف للـ secrets هيلتقطها في دقايق.

الخطوة 3: اكتب الـ workflow

اعمل ملف .github/workflows/stale-pr-reminder.yml بالمحتوى ده:

الـ cron: '0 7 * * 0-4' معناها: الدقيقة 0، الساعة 7 UTC (= 9 صباحاً القاهرة)، أيام الأسبوع من الأحد للخميس. الـ workflow_dispatch بيدّيك زرار "Run workflow" يدوي عشان تختبر بدون ما تستنى الجدولة. الـ GITHUB_TOKEN بيتولّد تلقائياً من GitHub لكل run وعنده صلاحية قراءة الـ pulls — مش محتاج تعمله انت.

الخطوة 4: اكتب السكربت

اعمل ملف .github/scripts/stale-pr.js بالمحتوى ده:

السكربت ده 38 سطر كاملاً، بدون أي dependency خارجي. fetch built-in في Node 20 من غير ما تنصّب node-fetch. octokit اختياري ولكنه بيضيف 4MB في node_modules بدون فايدة هنا، لأن إحنا بنعمل request واحد بس.

الخطوة 5: اختبر يدوياً

روح Actions tab في GitHub، اختار workflow Stale PR Reminder، واضغط Run workflow > Run workflow. لازم تستلم رسالة Slack خلال 30 ثانية. لو ما وصلتش، شيك على الـ Actions log من نفس الصفحة — السكربت بيطبع نص الخطأ كامل من GitHub أو Slack.

الأرقام والقياس على ريبو حقيقي

على ريبو فيه 24 PR مفتوحة وفريق 8 مهندسين، شغّلت البوت 6 أسابيع وقست:

• زمن استدعاء GitHub API: 280–420ms (مقاس عبر console.time في 30 تجربة).
• زمن إرسال الرسالة لـ Slack: 110–180ms.
• إجمالي وقت الـ workflow: ~12 ثانية شامل setup-node و checkout.
• استهلاك دقائق GitHub Actions الشهري: 12s × 5 أيام × 4 أسابيع ≈ 4 دقايق/شهر. الـ free tier بيدّيك 2000 دقيقة. التكلفة الفعلية: صفر دولار.
• متوسط زمن أول مراجعة على PR جديد: نزل من 5.4 يوم لـ 1.8 يوم خلال 6 أسابيع.
• عدد الـ PRs اللي قعدت فوق 7 أيام: نزل من 7 إلى 1 في نفس الفترة.

Trade-offs واضحة

كل قرار في البوت ده له ثمن. خليك واعي بـ 4 منهم قبل ما تنشره:

1. الفلترة client-side: مع 100+ PR، السكربت بيحمّل كل الـ list ويفلتر محلياً. لو تجاوزت 100 PR في صفحة واحدة محتاج pagination صريح بـ Link header. الثمن: تعقيد إضافي. المكسب: استعلام واحد لأقل من 100 PR.
2. updated_at مش created_at: لو حد رد على تعليق من ساعتين، الـ PR ميظهرش في القائمة حتى لو عمره 30 يوم. ده مقصود (ميتابعش PRs نشطة)، لكنه بيفوّت PRs اللي فيها نشاط سطحي بدون تقدّم حقيقي. لو ده مهم، استخدم created_at بدلاً منه.
3. إشعار يومي ثابت: أحياناً الفريق في deadline ومش عايز إزعاج. ضيف workflow_dispatch input عشان توقّفه أسبوع، أو خفّض التكرار لمرة كل أحد.
4. الاعتماد على Slack الرئيسي: لو القناة عليها 200 رسالة في اليوم، الإشعار هيغرق. وجّهها لقناة #pr-review منفصلة، أو استخدم thread reply على رسالة pinned بدل رسالة جديدة كل يوم.

متى لا تستخدم هذه الطريقة

التكتيك ده مش مناسب في 3 حالات:

• ريبوهات شخصية بـ 1–2 PR في الشهر — التذكير هنا ضوضاء أكتر من فايدة.
• monorepos فيها 500+ PR مفتوح — محتاج فلترة إضافية بـ labels أو reviewers أو path codeowners، مش مجرد عمر.
• منظّمات على GitHub Enterprise مع SSO صارم — استدعاء الـ API يحتاج إعداد scopes خاص ممكن يتعارض مع سياسات أمن المنظمة. كلّم الـ security team الأول.

الخطوة التالية

افتح أكبر ريبو من ريبوهاتك دلوقتي، أنشئ الملفين .github/workflows/stale-pr-reminder.yml و .github/scripts/stale-pr.js بنفس الكود فوق، ضيف الـ Slack webhook في secrets، وشغّله يدوياً مرة من Actions tab. لو الرسالة وصلت، الجدولة هتشتغل تلقائياً غداً صباحاً. لو الفريق عبّر إن الإشعار ضايقه، خفّض التكرار لمرة في الأسبوع بـ cron: '0 7 * * 0' بدل اليومي. لو لقيت إن في PRs بتظهر في القائمة كل يوم بدون تقدّم، ده مش مشكلة في البوت — ده مشكلة في الـ review process الأساسي محتاجة كلام صريح مع الفريق.

مصادر

• GitHub REST API — List pull requests: docs.github.com/en/rest/pulls/pulls#list-pull-requests
• Slack Block Kit Builder + reference: api.slack.com/block-kit و api.slack.com/messaging/webhooks
• GitHub Actions — Scheduled events وcron syntax: docs.github.com/en/actions/reference/events-that-trigger-workflows#schedule
• State of the Octoverse 2024 (إحصائيات PR review time): github.blog/2024-state-of-the-octoverse
• GitHub Actions — Free tier billing & minutes: docs.github.com/en/billing/managing-billing-for-github-actions
• GitHub Actions — Automatic GITHUB_TOKEN: docs.github.com/en/actions/security-guides/automatic-token-authentication