لا يُعتبر Coroid أن الإصدار قد تم نشره إلا إذا أشار CI/CD إلى ذلك. توضح هذه الصفحة كيفية إبلاغ خط أنابيب النشر عن عمليات النشر، سواء بدأها Coroid أو تم تنفيذها بشكل مستقل.
Coroid
مصنع CI/CD الخاص بك
البيئة
- 1.بدء للالتزام الدقيق
- 2.النشر الالتزام المحدد
- 3.تقرير يجري التنفيذ، ثم ينجح أو يفشل
- 4.مراقبة الحالة الصحية مع عملية التحقق من النسخة التجريبية
يتم تكوين كل ما يلي حسب بيئة التشغيل في قسم إعدادات ← إصدارات ← خط أنابيب النشر. قم بإنشاء رمز إبلاغ هناك. يمكن لمالك أو مشرف رؤيته مرة واحدة فقط. احفظه كرمز سري في خط أنابيب CI الخاص ببيئة التشغيل تلك. يحتفظ Coroid فقط بقيمة الهاش، ويؤدي استبدال الرمز إلى إلغاء صلاحية القديم فورًا. لا يمكن لرمز الإبلاغ هذا الإبلاغ إلا عن مشروعه وبيئة تشغيله. لا تضعه أبداً في ملف مستودع أو طلب متصفح.
إجراءات GitHub وGitLab CI/CD
إذا كنت ترغب في نشر إلى… زر في صفحة الإصدار، اختر Coroid يبدأ سير عمل إجراءات GitHub أو Coroid يبدأ خط أنابيب GitLab CI/CD
في إعدادات خط أنابيب النشر الخاصة بالبيئة. أدخل اسم مهمة النشر الدقيق، ومرجع الفرع أو العلامة، واسم ملف سير عمل GitHub عند الاقتضاء. يجب أن يشير هذا المرجع إلى التزام الإصدار وقت الطلب. يتلقى سير عمل GitHub coroid_release_id, coroid_attempt_id,
coroid_commit_sha, و coroid_environment مدخلات. يتلقى GitLab المتغيرات المقابلة بأحرف كبيرة COROID_* . استخدم هذه القيم للنشر والإبلاغ عن الـ SHA والمحاولة بدقة.
احفظ رمز رد الاتصال الخاص بالبيئة في أسرار إجراءات GitHub أو متغيرات GitLab CI/CD المقنعة. أرسل حدث running عند بدء مهمة النشر وحدث نهائي succeeded, failed, أو cancelled عند انتهائه. يتحقق Coroid من تشغيل المزود والتزامه ومهمته المسماة قبل قبول النجاح لخط أنابيب مُهيأ. يظل عنوان URL الخاص بتشغيل المزود هو المكان لفحص السجلات. سير عمل إنتاج Coroid سير عمل إنتاج Coroid
تحتوي على مثال عملي لـ GitHub Actions؛ قم بتعديل أسماء الأسرار والوظائف لتتناسب مع
مستودعك.
استدعاء CI عام
يمكن لخط أنابيب خارجي إرسال نفس الأحداث دون تفعيل عملية الإرسال. قم بمصادقة الهوية باستخدام رمز الوصول المحدد للبيئة. يقبل نقطة النهاية JSON بهذا الشكل المُرقّم:
POST /api/v1/release-deployment-events
Authorization: Bearer <environment-callback-token>
Content-Type: application/json{
"schemaVersion": 1,
"eventId": "ci:run-812:production:succeeded",
"providerRunId": "run-812",
"projectId": "<project-uuid>",
"environmentKey": "production",
"repository": "owner/repository",
"commitSha": "0123456789abcdef0123456789abcdef01234567",
"status": "succeeded",
"occurredAt": "2026-09-24T12:00:00Z",
"runUrl": "https://ci.example.com/runs/812"
}تضمين releaseId و attemptId عند الإبلاغ عن عملية تشغيل طلبتها
Coroid. failureReason يمكنه شرح سبب فشل العملية. استخدم queued, running,
succeeded, failed, أو cancelled من أجل status. احتفظ بنسخة واحدة من providerRunId
خلال عملية التشغيل، وأعطِ كل انتقال بين الحالات معرفًا فريدًا eventId. يجب أن يحتفظ إعادة المحاولة
للحدث نفسه بمعرفه؛ بينما تحتاج عملية CI الجديدة إلى معرف تشغيل جديد. يجب أن يكون طابع زمني للحدث حديثًا. تقوم Coroid بفحص المستودع والبيئة والالتزام ونطاق الاعتماد والحالة النهائية قبل تطبيقه؛ وتُؤجل الأحداث المتعارضة لمراجعتها. يمكن لعملية نشر صالحة بدون إصدار مُعدّ أن تُنشئ إصدارًا ملاحظًا، وهو يختلف تمامًا عن المرشح الذي تمت الموافقة عليه مسبقًا.
بالنسبة لخط أنابيب بدون استدعاءات، يمكن للمالك أو المشرف اختيار تسجيل نشر خارجي في صفحة الإصدار. قم بتحديد البيئة والالتزام المطابق والوقت بالإضافة إلى سبب أو رابط للدليل. تسجل شهادة التحقق اليدوية الناتجة النتيجة دون الادعاء بأن Coroid قد نفذ عمليات CI أو اجتاز الفحص.