أحداث النشر وإعدادات نظام التكامل المستمر

CoRoid يُعتبر الإصدار مُنتشرًا فقط عندما يؤكد ذلك CI/CD الخاص بك. توضح هذه الصفحة كيفية إبلاغ خط الأنابيب عن عمليات النشر، سواء بدأها CoRoid أو تم تنفيذها بشكل مستقل.

كل ما يلي يتم تكوينه حسب كل بيئة في مشروع إعدادات ← إصدارات ← خط أنابيب النشرقم بإنشاء رمز تقرير هناك. يراه المالك أو المشرف مرة واحدة فقط. احفظه كقيمة سرية في خط أنابيب CI الخاص بذلك البيئة. يحتفظ CoRoid فقط بقيمة التجزئة، وعند استبدال الرمز يتم إلغاء الصلاحية عن القديم فورًا. لا يمكن للرمز الإبلاغ إلا عن مشروعه وبيئته. لا تضعه أبداً في ملف مستودع أو طلب متصفح.

إجراءات GitHub وGitLab CI/CD#

إذا كنت ترغب في نشر إلى... زر على صفحة الإصدار، اختر CoRoid يبدأ سير عمل GitHub Actions أو CoRoid يبدأ خط أنابيب GitLab CI/CD في إعدادات خط أنابيب النشر الخاصة بالبيئة. أدخل اسم مهمة النشر الدقيق، ومرجع الفرع أو العلامة، واسم ملف سير العمل الخاص بـ GitHub عند الاقتضاء. يجب أن يشير هذا المرجع إلى التزام الإصدار وقت الطلب، ما لم يعلن سير عمل GitHub عن coroid_artifact_sha مدخلات (انظر أدناه). يتلقى سير عمل GitHub coroid_release_id، coroid_attempt_id، coroid_commit_sha، و coroid_environment مدخلات، بالإضافة إلى coroid_version، coroid_build_number، coroid_release_name و coroid_artifact_sha عندما يعلن سير العمل عنها. تتلقى GitLab المتغيرات المقابلة بأحرف كبيرة COROID_* . استخدم هذه القيم للنشر والإبلاغ عن الـ SHA وعدد المحاولات بدقة.

سير عمل GitHub الذي يعلن عن coroid_artifact_sha يتم تشغيله من مرجعه الخاص، عادةً فرعك الافتراضي، ويُنشر الالتزام الموجود في ذلك المدخل. يمكن لـ CoRoid بعد ذلك نشر أي إصدار، بما في ذلك العودة إلى إصدار أقدم، باستخدام سير العمل الحالي، ولم يعد المرجع مضطرًا للإشارة إلى التزام الإصدار. يسجل CoRoid التزام بدء التشغيل ويتحقق منه عند إبلاغ التشغيل عن النتيجة. يجب على سير العمل أيضًا تسجيل عملية نشر GitHub للالتزام المُنشر، بحيث ترتبط حالته بسير التشغيل، حيث يقرأ CoRoid معلومات النشر عندما يبدأ التشغيل من التزام آخر.

هناك مدخلان اختياريان آخران لجعل عمليات النشر آمنة للاستعادة:

• coroid_expected_revision هو التزام الذي كانت تعمل عليه البيئة عند طلب النشر. قارنه بما تعمل عليه البيئة قبل النشر. إذا اختلفا، فقد قام شخص ما بالنشر بينهما، لذا توقف دون نشر.
• coroid_rollback هو true عندما يقوم التشغيل بإعادة تعيين البيئة. خصص لمثل هذه التشغيلات مجموعة تزامن خاصة، حتى لا تنتظر عملية الإعادة وراء عملية النشر. قبل إعادة التعيين، يلغي CoRoid عملية النشر التي لا تزال قيد التشغيل وينتظر حتى تتوقف. إذا لم تتوقف في الوقت المحدد، لا يتم إعادة التعيين ويتم إخطار المالكين والمشرفين.

GitLab تتلقاهما كـ COROID_EXPECTED_REVISION و COROID_ROLLBACK. ضع الإصدار في بنائك توضح كيفية وسم الإصدار في البناء.

سمِّ كل تشغيل حسب محاولته، حتى يتمكن CoRoid من العثور على تشغيل لم يتلقَّ تأكيدًا عن بدءه. في GitHub Actions، قم بضبط run-name إلى نص يحتوي على coroid_attempt_id. في GitLab، قم بضبط workflow:name إلى نص يحتوي على $COROID_ATTEMPT_ID:

# GitHub Actions
run-name: ${{ inputs.coroid_attempt_id && format('Deploy (attempt {0})', inputs.coroid_attempt_id) || 'Deploy' }}

# GitLab CI/CD
workflow:
  name: 'Deploy $COROID_ATTEMPT_ID'

إذا بدأ CoRoid تشغيلًا ولكن مزود الخدمة لم يؤكد بدءه، فإن عملية النشر تنتظر. بعد 5 دقائق، يبحث CoRoid عن تشغيل يحتوي اسمه على معلومات المحاولة، وإذا وجده، يتابع ذلك التشغيل. وإذا لم يُعثر على تشغيل بعد 15 دقيقة، تنتهي عملية النشر كـ "مفقودة"، ويتم وضع علامة فشل على الإصدار، وتقبل البيئة عملية نشر جديدة.

قم بتخزين رمز رد الاتصال الخاص بالبيئة في قيم سرية لـ GitHub Actions أو متغيرات مشفرة لـ GitLab CI/CD. أرسل running حدث عند بدء مهمة النشر وحدث نهائي succeeded، failed، أو cancelled حدث عند انتهائه. يتحقق CoRoid من تشغيل مزود الخدمة والالتزام والوظيفة المسماة قبل قبول النجاح لخط أنابيب مُعدّ. يظل عنوان URL لتشغيل مزود الخدمة هو المكان المناسب لفحص السجلات.

سير عمل GitHub الذي يعمل من تزام واحد وينشر تزامًا آخر، مثل ذلك الذي يحتوي على ref مدخلات لنشر تزام أقدم أو العودة، يجب أن يحدد التزام الذي تم نشره. قم بإنشاء نشر GitHub للتزام المنشور في البيئة، وأعطِ حالته النهائية success الحالة log_url الذي يربط تشغيل سير العمل. بعد ذلك، يحتاج تطبيق GitHub إلى إذن المستودع . ال. مثال سير عمل إنتاج 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. أضف version و buildNumber لتسجيل ما قمت بنشره. بالنسبة لمشروع مضيف على CoRoid، repository هو معرّف المشروع. failureReason يمكنه تفسير سبب فشل التشغيل. استخدم queued، running، succeeded، failed، cancelled، أو rolled_back لـ statusتقرير rolled_back عندما قامت عملية التشغيل بترقية البيئة، ثم استعادت النسخة السابقة لأن النسخة الجديدة فشلت. احتفظ بنسخة واحدة providerRunId خلال عملية التشغيل وامنح كل انتقال بين الحالات معرفًا فريدًا eventId. يجب أن يحتفظ إعادة محاولة نفس الحدث بمعرفه؛ بينما تحتاج عملية تشغيل CI جديدة إلى معرف تشغيل جديد. إعادة تشغيل GitHub تحافظ على attemptId وتُبلغ عن محاولة التشغيل في providerRunId (<run id>-<run attempt>). إذا أعاد تشغيل أحدث عملية نشر للبيئة، يتبع CoRoid نفس عملية النشر. وإلا يسجله CoRoid كعملية نشر منفصلة لاحظها. يجب أن يكون طابع توقيت الحدث حديثًا. يتحقق CoRoid من المستودع والبيئة والالتزام ونطاق الاعتمادات وحالة النهاية قبل تطبيقه؛ وتُحتفظ بالأحداث المتعارضة للمراجعة. يمكن لعملية نشر صالحة بدون إصدار مُعدّ أن تُنشئ إصدارًا ملاحظًا، منفصلًا بوضوح عن المرشح الموافق عليه مسبقًا. يأخذ version الحدث يُبلغ عنه أو، عندما يخصص CoRoid إصدارات المشروع، الإصدار التالي.

الإصدار 2 من الحدث ("schemaVersion": 2) يُبلغ أيضًا عن هويتي عملية النشر: ما تم نشره وما نشره. artifact يحتوي على الالتزام المنشور، والذي يجب أن يساوي commitSha، وملخص كل صورة. workflow يحتوي على الالتزام الذي بدأت منه عملية التشغيل، واختياريًا مرجعه:

{
  "schemaVersion": 2,
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "artifact": {
    "sha": "0123456789abcdef0123456789abcdef01234567",
    "images": [{ "name": "app", "digest": "sha256:…" }]
  },
  "workflow": {
    "sha": "89abcdef0123456789abcdef0123456789abcdef",
    "ref": "owner/repository/.github/workflows/deploy.yml@refs/heads/main"
  }
}

يحتفظ CoRoid بحدث من الإصدار 2 للمراجعة عندما لا يكون التزام سير العمل هو نفسه التزام طلب النشر، أو عندما يُظهر مزود الخدمة أن التشغيل بدأ من التزام آخر. لا تزال أحداث الإصدار 1 مقبولة.

بالنسبة لخط أنابيب التشغيل بدون ردود استدعاء، يمكن للمالك أو المشرف اختيار تسجيل نشر خارجي في صفحة الإصدار. قم بتوفير البيئة والالتزام المطابق والوقت وسبب أو عنوان URL للدليل. تسجل شهادة التحقق اليدوية النتيجة دون الادعاء بأن CoRoid نفذ اختبارات CI أو اجتاز بوابة التحقق.

ذات صلة#

• إعدادات الإصدار
• إصدارات
• استعادة قطارات الإصدار
• ضَع الإصدار في بناءك