mirror of
https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools.git
synced 2026-06-18 15:29:36 +00:00
64 lines
4.2 KiB
Markdown
64 lines
4.2 KiB
Markdown
# حماية الفرع و CI — Dealix
|
|
|
|
**الغرض:** ربط **نجاح الدمج** ببوابات تقنية ثابتة، وتقليل دخول كود غير مختبر إلى `main` (أو فرع الإطلاق الذي تختاره).
|
|
|
|
**مرجع سير العمل:** [`.github/workflows/dealix-api-ci.yml`](../../.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`](../../.github/workflows/dealix-staging-smoke.yml) يدوياً بعد ضبط `STAGING_BASE_URL` في GitHub Secrets، ثم من الجهاز:
|
|
|
|
```bash
|
|
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](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks) و[Troubleshooting required status checks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks?apiVersion=2022-11-28&utm_source=chatgpt.com) وحماية الفروع.
|
|
|
|
---
|
|
|
|
## 3. ما لا يغطيه CI
|
|
|
|
- **لا** يثبت `PAID_BETA_READY` على استضافة حقيقية — ذلك يدوي أو عبر workflow staging بعد الأسرار.
|
|
- **لا** يستبدل عقداً أو تحصيلاً يدوياً — انظر [`PAID_BETA_OPERATING_PLAYBOOK.md`](PAID_BETA_OPERATING_PLAYBOOK.md).
|
|
|
|
---
|
|
|
|
**آخر تحديث:** 2026-05-01
|