Jenkins / أسس التنفيذ والمصدر / الدرس 3

سحب SCM وهوية الفروع المتعددة

اربط مراجعة Jenkinsfile والتطبيق المسحوب والسياق وأدلة المرشح.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى 2026-10-28

في هذه الصفحة

أهداف الدرس

فصل اكتشاف الفرع عن بناء مراجعة ثابتة.
مراجعة السحب دون الاتصال بإدارة المصدر.

الاكتشاف ليس تحقق التطبيق

تكتشف Multibranch Pipeline الفروع أو طلبات التغيير بحسب مصادر SCM وإضافاتها، وتبني سياقات مهام لملفات Jenkinsfile. يحدد الاكتشاف ما يُنظر فيه، ثم يفحص التشغيل مصدراً وإعداداً معينين. لا يثبت نجاح الفهرسة تجميع التطبيق أو ثقة الاقتراح. افصل مستودع Parcel وهوية الفرع أو الطلب ومنشأ التعريف والمراجعة المسحوبة. قد تؤثر استراتيجية الثقة الخاصة بالإضافة في التعريف المستخدم لتغيير غير موثوق، لذا راجع التركيب الفعلي. لا يمكن لاسم نوع المهمة وحده وصف كل هذه القرارات أو إثبات أنها اختبرت الشيفرة.

لسياق المصدر معنى محدد

في سياق مناسب من Pipeline-from-SCM أو multibranch، تستخدم checkout scm إعداد المصدر المرتبط بالتشغيل، ولا تعني دائماً أحدث فرع افتراضي. تنفذ Declarative عادة سحباً افتراضياً في سياق وكيل مناسب ما لم يُضبط غير ذلك. قد ينتج سحب يدوي إضافي عمليات مكررة أو مدخلات متعارضة. حدد من يملك السحب واحفظ المراجعة المحلولة. يصرح المثال بالملكية مع افتراض سياق SCM قائم صالح؛ لا ينشئ مستودعاً ولا يثبت أذونات الوصول أو توفر إضافة لم تُفحص هنا.

groovy توضيح ملكية السحب صراحة

pipeline {
    agent { label "parcel-lab" }
    options { skipDefaultCheckout(true) }
    stages {
        stage("Source") {
            steps { checkout scm }
        }
    }
}

يلزم وجود الوسم وSCM والمستودع والإضافات والوصول في مختبر مصرح. لا يحدث جلب أو سحب أو اتصال مستودع أو تشغيل Jenkins هنا.

يختلف رأس التغيير ونتيجة الدمج

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

طابق الدليل بالمراجعة المقصودة

يفحص النموذج المحلي الكامل تطابق مراجعة كل ملاحظة مطلوبة مع مصدر المرشح. يرفض نتيجة وحدة لمراجعة أخرى رغم success. الأسماء lab-r4 افتراضية وليست تجزئات Git. تحتاج الحقيقة سجلات منتج موثقة وهوية محتوى ثابتة، لا ادعاء مساهم. لا ينفذ النموذج بروتوكول SCM أو حساب دمج أو سلوك إضافة. يوضح علاقة الدليل بالمصدر بلا مستودع بعيد. كما يصرح بأن مجموعة الفحوص المطلوبة حد آخر يجب إثباته؛ فمطابقة مراجعات مجموعة ناقصة لا تكفي وحدها للإصدار.

python رفض دليل لمراجعة مصدر أخرى

candidate_revision = "lab-r4"
evidence = {"compile": {"revision": "lab-r4", "ok": True}, "unit": {"revision": "lab-r3", "ok": True}}
ready = all(v["ok"] and v["revision"] == candidate_revision for v in evidence.values())
print(ready)
print(sorted(k for k, v in evidence.items() if v["revision"] != candidate_revision))

الناتج المتوقع

False
['unit']

يقيم البرنامج قواميس افتراضية فقط. تحتاج بوابة حقيقية مجموعة الفحوص المطلوبة أيضاً؛ يعزل المثال مطابقة المراجعة ولا يمثل شرط إصدار كاملاً.

لا يفوض وصول SCM تنفيذ المصدر

تتيح قراءة المستودع الحصول على البايتات ولا تجعل كل فرع أو نسخة متفرعة آمنة مع الاعتمادات. راجع من يعدل Jenkinsfile ونصوص البناء والخطافات ومراجع المكتبة. قد ينفذ تعريف موثوق شيفرة تطبيق غير موثوقة بأمر بناء عادي. افصل تحقق الاقتراح المقيد عن ترقية المرشح المميزة وأبعد الأسرار عن سجل المراجعة التشخيصي. يبقى الحد مطلوباً حتى مع تحقق إضافة السحب من الهوية الصحيحة؛ فإثبات هوية محتوى غير موثوق لا يغير سلطته ولا يحوله تلقائياً إلى تنفيذ مصرح.

الأخطاء الشائعة وإصلاحها

يُعرض نجاح فهرسة الفروع كأنه نجاح بناء التطبيق.

لماذا يحدث؟: توسع معنى دليل الاكتشاف إلى تنفيذ لم يُثبت حدوثه.
كيف تصلحه؟: افحص التشغيل الفعلي ونتائج الاختبارات المطلوبة بدلاً من الاكتفاء بالفهرسة.
كيف تتجنب تكراره؟: افصل حالات الاكتشاف والسحب والتحقق في التقارير.

يحل السحب اليدوي والافتراضي مدخلات مصدر متعارضة.

لماذا يحدث؟: لم تُحدد الجهة المالكة للسحب على مستوى Pipeline.
كيف تصلحه؟: اختر مسار سحب مقصوداً واحفظ الهوية التي حلها فعلاً.
كيف تتجنب تكراره؟: راجع إعداد السحب الافتراضي عند إضافة خطوة SCM يدوية.

تستوفي حالة ناجحة لمراجعة أقدم متطلبات مرشح جديد.

لماذا يحدث؟: اختير الدليل باسم الفحص بدلاً من علاقة المراجعة بالمرشح.
كيف تصلحه؟: اشترط المراجعة الثابتة المقصودة لكل ملاحظة إلزامية.
كيف تتجنب تكراره؟: احفظ هويتي المصدر والتركيب المختبر مع النواتج وأدلتها.

اختبر فهمك

1. لم يتغير رأس الاقتراح لكن الفرع الهدف تقدم. هل تبقى نتيجة التركيب السابقة كافية تلقائياً؟

اعرض الحل المشروح

لا. ربما تغيرت حالة الدمج التي يجب اعتمادها رغم ثبات الرأس. طبق سياسة إعادة التحقق المدعومة للمستودع وسجل التركيب الذي اختُبر فعلاً. يجيب دليل الرأس ودليل الشجرة المجمعة عن سؤالين مختلفين.

2. لماذا لا توصف checkout scm بأنها تسحب أحدث main دائماً؟