mancitrus/system-prompts-and-models-of-ai-tools
1
0
Fork 0
mirror of https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools.git synced 2026-06-17 14:59:35 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
c0490733d4
system-prompts-and-models-o.../dealix/docs/BRANCH_PROTECTION_AND_CI.md
Sami Assiri 4f02f54019 docs: finalize commercial go-live checklist 
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-01 18:59:34 +03:00

4.2 KiB
Raw Blame History

حماية الفرع و CI — Dealix

الغرض: ربط نجاح الدمج ببوابات تقنية ثابتة، وتقليل دخول كود غير مختبر إلى main (أو فرع الإطلاق الذي تختاره).

مرجع سير العمل: .github/workflows/dealix-api-ci.yml في جذر المونوريبو.

1. ما الذي يشغّله CI اليوم؟

Workflow باسم Dealix API CI يحتوي على ثلاثة jobs منفصلة (لتعيينها كـ required status checks في GitHub):

Job ID ماذا يفعل
pytest compileall + pytest -q --no-cov + placeholder الـ embeddings + run_evals
smoke_inprocess python scripts/smoke_inprocess.py
launch_readiness python scripts/launch_readiness_check.py (بوابة GO_PRIVATE_BETA محلياً)

Staging و PAID_BETA_READY: لا يُشغَّل تلقائياً على كل PR (يحتاج URL وأسرار بيئة). استخدم .github/workflows/dealix-staging-smoke.yml يدوياً بعد ضبط STAGING_BASE_URL في GitHub Secrets، ثم من الجهاز:

python scripts/launch_readiness_check.py --base-url "$STAGING_BASE_URL"

2. إعداد Branch protection في GitHub

  1. Settings → Branches → Add branch protection rule (أو تعديل قاعدة موجودة) للفرع المحمي (مثلاً main).

  2. فعّل على الأقل:

    • Require a pull request before merging
    • Require status checks to pass before merging
    • Require branches to be up to date before merging (موصى به)
    • Block force pushes
    • Block branch deletion (للفرع الرئيسي، إن وُجد الخيار)
    • Require conversation resolution before merging (إن كان الفريق يستخدم مراجعات على التعليقات)

  3. في Status checks that are required، أضف الثلاثة التالية (الأسماء كما تظهر غالباً بعد أول تشغيل للـ workflow):

    • pytest
    • smoke_inprocess
    • launch_readiness

    إن ظهرت مُسبوقة باسم الـ workflow، اختر الصيغة التي يعرضها GitHub (مثل Dealix API CI / pytest).

  4. ظهور الـ checks في القائمة: GitHub يعرض عادةً الـ checks التي اكتملت بنجاح خلال آخر سبعة أيام حتى تُختار كـ required — إن لم تظهر الأسماء، شغّل الـ workflow مرة ناجحة (أو ادفع commit يمرّر الـ CI).

  5. تفرّد أسماء الـ jobs: تجنّب تكرار نفس اسم job في workflows متعددة على نفس الريبو؛ قد يسبب تضارباً في نتائج status checks ويعطّل الدمج أو يربك القاعدة. احتفِ بـ pytest / smoke_inprocess / launch_readiness داخل Dealix API CI كمصدر واحد للبوابة على كل PR.

  6. اسم check مزدوج: إذا ظهر check وstatus بنفس الاسم في القائمة، اختيار ذلك الاسم كـ required قد يجعل الاثنين مطلوبين — راجع أسماء الـ workflow/job في الواجهة قبل الحفظ.

المرجع: وثائق GitHub عن required status checks وTroubleshooting required status checks وحماية الفروع.

3. ما لا يغطيه CI

  • لا يثبت PAID_BETA_READY على استضافة حقيقية — ذلك يدوي أو عبر workflow staging بعد الأسرار.
  • لا يستبدل عقداً أو تحصيلاً يدوياً — انظر PAID_BETA_OPERATING_PLAYBOOK.md.

آخر تحديث: 2026-05-01