كيفية إعداد مسارات التكامل المستمر (CI) لـ GitLab على Ubuntu 20.04

يفهم كل مطور مدى أهمية التحكم في الإصدارات لدورة حياة تطوير البرمجيات. فهو يتيح لعدة أشخاص العمل في وقت واحد على مشروع واحد، حيث يحتفظ كل شخص بنسخته الخاصة من الكود ويختار متى يشاركها مع بقية أعضاء الفريق. ولتحقيق ذلك، يستعين المطورون بـ Git لمساعدتهم في التحكم في الإصدارات. GitLab هو مستودع Git قائم على الويب وهو أكثر من مجرد أداة للتحكم في الإصدارات. كما أنه يوفر أدوات DevOps، وتتبع المشكلات، والتكامل المستمر، والنشر.

يقدم GitLab ثلاثة خيارات يمكنك الاختيار من بينها: GitLab Community Edition (CE) وGitLab Enterprise Edition (EE) وGitLab SaaS. GitLab CE وGitLab EE هما حلان مداران ذاتيًا. وهذا يعني أنه يمكنك تنزيل نسخة GitLab وتثبيتها وإدارتها بنفسك. يتم استضافة GitLab SaaS بواسطة شركة GitLab Inc. وبالتالي، لا داعي للقلق بشأن تثبيت أي شيء لاستخدامه. كل ما تحتاجه هو إنشاء حساب GitLab والبدء.

في هذا البرنامج التعليمي، سنوضح لك كيفية إعداد مسارات التكامل المستمر باستخدام GitLab CI لمراقبة مستودعاتك بحثًا عن التغييرات وتشغيل اختبارات مؤتمتة للتحقق من صحة الكود الجديد. سنبدأ بإعداد مستودع Git لاستضافة الكود. بعد ذلك، سنقوم بتكوين عملية CI لمراقبة عمليات الإرسال (commits) إلى المستودع وبدء تشغيل CI runner لتشغيل الاختبارات في حاوية Docker معزولة.

المتطلبات الأساسية

للبدء، ستحتاج إلى خادم يقوم بتشغيل برنامج التحكم في الإصدار GitLab. يمكن لكل من GitLab المدار ذاتيًا وSaaS تشغيل اختبارات مؤتمتة. ومع ذلك، هناك بعض القيود من حيث الدقائق والموارد المتاحة لاختباراتك في خيارات SaaS المجانية. تتمتع بحرية أكبر إذا كنت تستخدم الخيارات المدارة ذاتيًا لأنه يمكنك تخصيص أي قدر تريده من الموارد لنسخة GitLab الخاصة بك. اتبع برنامجنا التعليمي حول استضافة مستودعات Git الخاصة بك باستخدام GitLab لمعرفة كيفية إعداد نسخة GitLab الخاصة بك.

ستحتاج إلى خادم واحد على الأقل لاستخدامه كـ GitLab CI runner. ومع ذلك، يمكنك استخدام المزيد من الخوادم أيضًا إذا أردت. إذا قمت بإعداد نسخة GitLab مدارة ذاتيًا، فيمكنك استخدام نفس الخادم، ولكننا نفضل إعداد خادم مختلف لـ CI runner. هذا البرنامج التعليمي حول كيفية إعداد خادم Ubuntu الخاص بك هو بداية جيدة.

ستحتاج إلى تثبيت Docker على خوادم GitLab CI runner لعزل بيئات الاختبار في حاويات Docker. لدينا برنامج تعليمي حول كيفية تثبيت وتشغيل Docker على Ubuntu يمكنه مساعدتك في إكمال هذا المتطلب.

الآن بعد أن أصبح لدينا كل ما نحتاجه، فلنبدأ!

الخطوة 1: إنشاء مشروع على نسخة GitLab

سنبدأ بإنشاء مستودع مشروع على GitLab. سنبني هذا البرنامج التعليمي على Node.js application. وبما أننا لا نريد إنشاء ملفات المشروع من الصفر، فإن GitLab يوفر أداة لاستيراد المشاريع من مستودعات التحكم في الإصدار الأخرى والتي سنستفيد منها. التطبيق الذي سنستورده هو تطبيق بسيط لـ “hello world” مبني باستخدام Express.js – إطار عمل ويب بسيط لتطبيقات Node.js. سنقوم بتنفيذ الاختبارات باستخدام Mocha و Chai – هذه هي أطر عمل JavaScript المستخدمة لاختبار الوحدات (unit testing). يتيح Mocha الاختبار غير المتزامن، وتقارير تغطية الاختبار، ويمكن إقرانه بمكتبات تأكيد (assertion) أخرى. Chai هي مكتبة تأكيد. يمكن إقرانها بأي إطار عمل اختبار، وفي حالتنا هذه، سنقوم بإقران Mocha مع Chai.

الآن بعد أن عرفت أساسيات مشروعنا، قم بتسجيل الدخول إلى نسخة GitLab الخاصة بك (سواء كانت مدارة ذاتيًا أو SaaS)، وانقر على أيقونة ‘زائد’ في شريط التنقل العلوي، وحدد ‘New project’: اختياريًا، إذا قمت بالتمرير إلى أعلى الصفحة الرئيسية لحسابك، يمكنك النقر على زر ‘New project’:

في صفحة المشروع الجديد، انقر فوق علامة التبويب Import project:

بعد ذلك، في الصفحة المفتوحة، انقر فوق زر Repo by URL:

على الرغم من وجود خيار استيراد من GitHub، إلا أننا لن نستخدمه لأنه يتطلب رمز وصول شخصي (Personal access token). لا نحتاج إلى إعداد رموز وصول شخصية لأننا نعمل مع مستودع عام، والاستيراد باستخدام عنوان URL فقط أمر بسيط ومباشر.

بعد ذلك، انسخ عنوان URL التالي والصقه في حقل Git Repository URL:

يجب أن يبدو الأمر كالتالي:

اترك المستودع كـ Private وانقر على زر Create project عند الانتهاء. انتظر بضع ثوانٍ حتى يتم استيراد المشروع من GitHub وسيظهر ضمن مستودعات GitLab الخاصة بك. يقوم GitLab باستيراد المشروع بنفس تفاصيل مشروع مستودع GitHub.

الخطوة 2: تحليل ملف .gitlab-ci.yml

يقوم GitLab CI بفحص كل مستودع على GitLab بحثًا عن ملف يسمى .gitlab-ci.yml لمعرفة كيفية تشغيل الاختبارات الآلية. في المستودع الذي قمنا باستيراده للتو، يمكنك رؤية ملف .gitlab-ci.yml بين ملفات المشروع. يمكنك العثور على مزيد من المعلومات حول GitLab CI yml في موقعهم الرسمي مرجع الكلمات المفتاحية لتوثيق ملف .gitlab-ci.yml.

أثناء وجودك في واجهة مستودع GitLab، انقر على ملف .gitlab-ci.yml لفتحه في صفحة المتصفح. يجب أن يبدو كالتالي:

لاحظ مسافة البداية للسطور. يتبع الملف صيغة تكوين GitLab CI YAML صارمة لتحديد الإجراءات المختلفة التي يجب اتخاذها، بترتيب معين وتحت شروط معينة. لضمان صحة ملفات التكوين الخاصة بك، يوفر GitLab أداة اختبار للتحقق من الصحة. داخل نسخة GitLab الخاصة بك، في مستودع مشروعك، يمكنك زيارة واجهة CI lint للتحقق من صحة ملف .gitlab-ci.yml. انقر على CI/CD في قائمة التنقل اليسرى، وانقر على زر CI lint في الصفحة التي تظهر:

تتم مناقشة التوجيهات الواردة في ملف التكوين أدناه.

• صورة Docker الأساسية

يصرح السطر الأول في ملف التكوين عن صورة Docker التي يجب استخدامها لتشغيل الاختبارات. نظرًا لأننا نقوم ببناء تطبيق Node.js، فإننا سنستخدم أحدث صورة لـ Node.js:

• المراحل

بعد ذلك، نحدد المراحل المختلفة التي نريد أن تمر بها اختبارات التكامل المستمر لدينا. لدينا مرحلتان فقط:

أثناء تحديد أسماء المراحل، يتم اختيار أسماء مثل build أو test بشكل عشوائي – يمكنك اختيار أي اسم تريده. ومع ذلك، يجب عليك ترتيب المراحل بشكل صحيح لأن ذلك يحدد تدفق التنفيذ. في حالتنا، يتم تنفيذ المهام في مرحلة build قبل المهام في مرحلة test . سيقوم GitLab runner بتنفيذ المهام في نفس المرحلة بالتوازي وسينتظر اكتمال جميع المهام قبل البدء في تنفيذ المهام في المرحلة التالية.

• التخزين المؤقت

يتم تضمين تعريف cache لتحديد الملفات والأدلة التي سيتم تخزينها مؤقتًا أو حفظها للاستخدام لاحقًا بين عمليات تشغيل المهام:

يساعد تحديد التخزين المؤقت في تقليل الوقت المستغرق لتشغيل المهام التي تعتمد على موارد من غير المحتمل أن تتغير بين عمليات التشغيل. نحدد دليل node_modules ليتم تخزينه مؤقتًا. هذا هو الدليل الذي يقوم npm بتثبيت الاعتماديات للمشروع فيه.

• المهام

لدينا مهمتان في التكوين:

• install_dependencies

عند تسمية المهام، أنت حر في اختيار أي اسم. ومع ذلك، يوصى باختيار اسم وصفي نظرًا لاستخدامها في واجهة مستخدم GitLab – يمكن أن يكون هذا مفيدًا أثناء تصحيح الأخطاء. ستجد معظم التكوينات على الويب تجمع بين npm install مع الأوامر في مرحلة الاختبار. لقد قمنا بفصلهما فقط للمساعدة في توضيح كيفية تفاعل الوظائف بما أن هذا المشروع صغير نوعًا ما. الـ stage يحدد هذا التوجيه هذه الوظيفة كـ build – حيث يتم تشغيلها في الـ build stage.

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

الـ artifacts يحدد التوجيه ملفات أو مسارات مجلدات لحفظها ومشاركتها بين المراحل. مجددًا، نذكرك بأن ترتيب المراحل بشكل صحيح أمر بالغ الأهمية لضمان حصول الملفات الأخرى على ما تحتاجه للتنفيذ. أمر npm install سيقوم بتثبيت التبعيات في مجلد node_modules. من خلال الإعلان عنه في artifacts، نجعله متاحًا للوظائف التي يتم تنفيذها في المراحل اللاحقة. تتوفر الملفات أيضًا في واجهة مستخدم GitLab إذا كنت ترغب في تنزيلها.

• test_with_mocha

يتم تشغيل هذه الوظيفة في مرحلة test. وبما أن هذه الوظيفة تعمل بعد تشغيل الوظيفة في مرحلة build، فإن الـ artifacts المعلن عنها في مرحلة build (والتي هي التبعيات الخاصة بتطبيقنا) ستكون متاحة لمرحلة test. تحدد كتلة script أوامر npm لتشغيل اختباراتنا. نقوم أولاً ببدء تشغيل تطبيقنا ثم تشغيل الاختبارات عليه. يؤدي تشغيل هذه الأوامر إلى إطلاق الأوامر المحددة في قسم كتلة البرامج النصية في package.json:
مع ذلك، يجب أن يكون لديك الآن فهم أساسي لملف .gitlab-ci.yml. ونقول أساسي لأن هذا مجرد تطبيق hello world ساكن. بعد ذلك، دعنا نرى كيف يمكننا تحفيز تشغيل CI جديد.

الخطوة 3: تحفيز تشغيل GitLab CI

سيسعدك معرفة أنه بمجرد أن يحتوي المستودع الخاص بك على ملف .gitlab-ci.yml، فإن أي عمليات إيداع جديدة تدفعها إليه ستحفز تشغيل تكامل مستمر جديد. في حالة نسخ GitLab المدارة ذاتيًا، إذا لم تقم بتكوين GitLab runner، فسيتم تعيين تشغيل CI على "معلق" (pending).

يوفر GitLab SaaS للمستخدمين بعض المشغلات المشتركة (shared runners) التي يمكنها التقاط وظائفهم وتنفيذها تلقائيًا. لا يمكن ذلك إلا إذا كانت المشغلات المشتركة شاغرة ولم تتجاوز حصتك المحددة. في GitLab SaaS، يمكنك اختيار ما إذا كنت تريد أن يستخدم المستودع الخاص بك shared runners أم لا من خلال الانتقال إلى صفحة Settings > CI / CD الخاصة بمشروعك كما هو موضح في لقطة الشاشة أدناه. في هذه الصفحة، ستجد أيضًا معلومات حول تعليمات تثبيت GitLab runner والتي سنتعمق فيها في الخطوة التالية:

الآن، دعنا نجري تغييرًا بسيطًا لتحفيز تشغيل CI. انتقل مجددًا إلى مستودع مشروع GitLab الخاص بك node_pipeline :

انقر على ملف README.md الموضح أعلاه لعرضه:

انقر على زر ‘Edit’ لفتح الملف للتحرير في المتصفح، وأضف بعض النص:

بمجرد إضافة بعض النص، مرر لأسفل وانقر على زر Commit changes لحفظ التغييرات. يمكنك تعديل رسالة الإيداع كما تشاء. ستظهر كعنوان في واجهة مستخدم GitLab عندما يكون خط الأنابيب قيد التشغيل. لقد تركناها كـ Update README.md لأنها وصفية للغاية:

بمجرد إيداع التغييرات، عد إلى صفحة المشروع الرئيسية. ستلاحظ وجود أيقونة إيقاف مؤقت صغيرة مرفقة بأحدث إيداع. إذا قمت بتمرير مؤشر الماوس فوق الأيقونة، فستعرض: ‘Pipeline:pending’:

هذا يعني أنه تم تحفيز تشغيل CI. ومع ذلك، لم يتم تشغيل الاختبارات بعد. في قائمة التنقل على اليسار، انقر على CI/CD، ثم حدد Pipelines. سيؤدي هذا إلى فتح صفحة تعرض المزيد من التفاصيل حول خط الأنابيب. يمكنك رؤية أن الـ CI معلق ومميز بأنه عالق:

للحصول على مزيد من التفاصيل حول التشغيل، انقر على حالة pending. سترى العرض أدناه، والذي يعرض المراحل المختلفة للتشغيل، والوظائف الفردية المرتبطة بكل مرحلة:

يمكنك أيضًا النقر على الوظائف الفردية لرؤية تفاصيلها الدقيقة مثل سبب التأخير. في حالة عمليات التشغيل الفاشلة، هنا سترى ما الذي تسبب في فشل الوظيفة:

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

الخطوة 4: إعداد خدمة GitLab CI Runner

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

لديك خيار نشر الـ runner على نفس الخادم الذي يستضيف مثيل GitLab المدار ذاتيًا. ومع ذلك، لضمان عدم تقييد المثيل بالموارد، يفضل إعداد مثيل CI runner منفصل. أياً كان التكوين الذي تختار المضي قدمًا فيه، يجب تثبيت Docker لعزل بيئات الاختبار.

عملية تثبيت GitLab CI runner تشبه تلك الخاصة بـ تثبيت مثيل GitLab المدار ذاتيًا المدار ذاتيًا. نبدأ بتنزيل سكربت لإضافة مستودع GitLab الرسمي إلى مصادر apt باستخدام الأمر التالي:

أدخل كلمة مرور root الخاصة بك عندما يُطلب منك ذلك. بعد ذلك، يمكنك الآن تشغيل الأمر لتثبيت أحدث إصدار من GitLab CI runner:

يقوم الأمر أعلاه بتثبيت وتسجيل خدمة runner جاهزة للاستخدام من قبل مشاريعك.

الخطوة 5: الحصول على رموز التسجيل وربط GitLab Runner

لإعداد GitLab CI runner لبدء قبول الوظائف، تحتاج إلى رمز (token) لـ GitLab runner. وهو مطلوب لكي يقوم الـ runner بالمصادقة مع مثيل خادم GitLab الخاص بك. هناك نوعان من الرموز اعتمادًا على كيفية استخدامك للـ runner: خاص بالمشروع (project-specific) و runner مشترك (shared runner).

الـ runners الخاصة بالمشروع قابلة للتطبيق إذا كانت لديك متطلبات فريدة للـ runner. على سبيل المثال، إذا كانت لديك تعريفات نشر في ملف gitlab-ci.yml برموز فريدة، فقد يوصى باستخدام runner معين للمصادقة بشكل صحيح في بيئة النشر. وهناك اعتبار آخر وهو ما إذا كانت مراحل التكامل المستمر لديك تحتوي على عمليات تستهلك الكثير من الموارد. حينها، سيكون من المثالي استخدام runner خاص بالمشروع. لاحظ أن الـ runner الخاص بالمشروع لا يقبل وظائف من مشاريع أخرى.

الـ runners المشتركة هي للأغراض العامة ويمكن استخدامها من قبل مشاريع متعددة. يحتوي مثيل GitLab SaaS المستضاف على GitLab Inc على بعض الـ runners المشتركة التي ستلتقط خطوط الأنابيب (pipelines) الخاصة بك تلقائيًا كما هو موضح في الخطوة الثالثة. تأخذ الـ runners الوظائف من التكوينات الخاصة بك بناءً على خوارزمية تأخذ في الاعتبار عدد الوظائف التي يتم تنفيذها حاليًا لكل مشروع. الـ runner المشترك أكثر مرونة من الـ runner الخاص بمشروع معين. ويمكن تكوينه من حساب المسؤول لمثيل GitLab. دعنا نرى كيف يمكننا الحصول على الرموز لكلا الـ runners.

• تسجيل Runner خاص بالمشروع

لتسجيل runner خاص بالمشروع، افتح مشروعك في مثيل GitLab أو حساب GitLab SaaS الخاص بك. من قائمة التنقل على اليسار، انقر فوق عنصر Settings ثم حدد خيار CI/CD :

بعد ذلك، قم بالتمرير لأسفل إلى قسم Runners وانقر على الزر لتوسيع القسم:

يوضح الجانب الأيسر كيفية تسجيل runner خاص بالمشروع. هذا عرض لمثيل GitLab SaaS. يمكنك أيضًا تكوين runners تلقائية باستخدام Kubernetes، ولكننا نقوم بإعداد الـ runner اليدوي في هذا البرنامج التعليمي:

بعد ذلك، تحتاج إلى التركيز على القسم الذي يتم فيه إعطاؤك رمز المرور (token) لهذا المشروع. بالنسبة لنسخة GitLab المدارة ذاتيًا، سيعرض عنوان URL نطاق الخادم الذي تعمل عليه نسخة GitLab الخاصة بك:

يمكنك اختيار تعطيل الـ runners المشتركة لهذا المشروع عن طريق تبديل المفتاح في القسم الأيمن تحت Shared Runners. ثم، انسخ رمز التسجيل المعروض إلى المفكرة الخاصة بك، حيث سنستخدمه لاحقًا.

• تسجيل Runner مشترك

لتسجيل runner مشترك، تحتاج إلى تسجيل الدخول إلى نسخة GitLab المدارة ذاتيًا كمسؤول. للوصول إلى لوحة التحكم، انقر فوق أيقونة مفتاح الربط/المفك في قائمة التنقل العلوية:

في Admin Panel، انقر على Runners في قسم Overview من القائمة اليسرى. سيؤدي هذا إلى فتح صفحة تحتوي على تعليمات تكوين Shared Runners :

انسخ رمز التسجيل المعروض على الجانب الأيمن تحت إعداد Runner مشترك يدويًا. ستستخدم هذا الرمز لتسجيل الـ runner في الخطوة التالية.

• ربط GitLab CI Runner بنسخة GitLab

في هذه الخطوة، ستقوم بربط نسخة GitLab الخاصة بك بـ CI runner. قم بتسجيل الدخول مجددًا إلى الخادم الذي قمت بتثبيت خدمة GitLab runner عليه في الخطوة الرابعة. لبدء عملية تسجيل الـ runner، أدخل الأمر التالي في الطرفية الخاصة بك:

يطالبك الأمر بسلسلة من الأسئلة:

• أدخل عنوان URL لنسخة GitLab (على سبيل المثال، https://gitlab.com/):

أدخل اسم نطاق نسخة GitLab الخاصة بك باستخدام https:// لتحديد SSL.

• أدخل رمز التسجيل:

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

• أدخل وصفًا للـ runner:

اختر اسمًا وصفيًا لـ CI runner الخاص بك كما سيظهر في واجهة مستخدم نسخة GitLab.

• أدخل منفذًا (executor): custom, docker-ssh, parallels, virtualbox, docker, shell, ssh, docker+machine, docker-ssh+machine, kubernetes:

هنا، يوفر لك خيارات لاختيار منفذ (executor) لتشغيل المهام. أدخل Docker.

• أدخل علامات (tags) للـ runner (مفصولة بفواصل):

هذا اختياري. يمكنك إدخال أي أسماء علامات مثل التبعيات التي يتضمنها هذا الـ runner. يمكنك تركها فارغة في الوقت الحالي.

• أدخل صورة Docker الافتراضية (على سبيل المثال، ruby:2.6):

هنا، يُتوقع منك تحديد صورة افتراضية للأغراض العامة تُستخدم لتشغيل المهام في حال لم يحدد ملف gitlab-ci.yml صورة معينة. أدخل alpine:latest نظرًا لأنها صورة صغيرة وآمنة وللأغراض العامة. اضغط على Enter وسيتم تسجيل الـ runner وتشغيله تلقائيًا:

لعرض قائمة الـ runners المتاحة حاليًا، أدخل الأمر التالي:

الخطوة 6: التأكد من ربط CI Runner بنجاح في GitLab

بعد ذلك، عد إلى متصفحك وقم بزيارة صفحة مشروعك في نسخة GitLab. اعتمادًا على عدد الدقائق التي مرت منذ تسجيلك للـ runner، قد ترى أن المهمة قيد التشغيل حاليًا:

أو ربما تكون قد اكتملت:

بعد ذلك، انتقل إلى صفحة Pipelines إما من خلال القائمة اليسرى CI/CD > Pipelines، أو بالنقر على أيقونة running, passed, أو failed (إذا واجه خط الأنابيب أخطاء) لعرض حالة تشغيل CI. هنا يمكننا رؤية أن إحدى المراحل (build stage) قد نجحت، بينما لا تزال هناك مرحلة أخرى قيد التشغيل:

في الجدول، تحت عنوان Stages، انقر على إحدى أيقونات المراحل لعرض المهام المرتبطة بها:

ثم، انقر على مهمة في النافذة المنبثقة لعرض التفاصيل:

تم تشغيل المهمة ويمكنك رؤية التقدم عندما كان أمر npm يقوم بتثبيت التبعيات. على الجانب الأيمن، يمكنك عرض معلومات أخرى ذات صلة. لديك خيار لتنزيل النتائج (artifacts) من المهمة. يمكنك أيضًا التبديل بين المراحل لعرض مهام أخرى من القائمة المنسدلة.

هنا، يمكنك عرض حالات الاختبار الخاصة بنا والتي تظهر عند تحديد المهمة في مرحلة الاختبار:

الـ Runners المتاحة

في القائمة اليسرى، إذا نقرت على Settings > CI/CD، وقم بتوسيع Runners قسم، يجب أن ترى الـ runner الذي قمت بتسجيله للتو. اعتمادًا على ما إذا كنت قد حددت رمزًا مميزًا خاصًا بالمشروع أو رمزًا مميزًا مشتركًا، سيظهر الـ runner في القسم المقابل على التوالي.

هنا يمكنك أن ترى أننا قمنا بتسجيل رمز مميز خاص بالمشروع. يظهر الـ runner تحت Specific Runners:

الخاتمة

في هذا الدرس التطبيقي، تعلمت كيفية أتمتة اختباراتك باستخدام GitLab CI. لقد بدأنا بإعداد مشروع تطبيق Node.js على GitLab. تضمن المشروع بعض حالات الاختبار وgitlab-ci.yml. وتعلمنا أن GitLab يستخدم ملف gitlab-ci.yml لتحديد ما يجب فعله عند تشغيله. ملف gitlab-ci.yml هو مجرد ملف تكوين يحتوي على تعليمات حول بناء التطبيقات واختبارها، وهو مكتوب بتنسيق YAML الذي يمكن لـ GitLab CI runner فهمه.

لقد تمكنا أيضًا من إعداد GitLab CI runner على مضيف منفصل. وقمنا بتسجيله لتلقي المهام من مثيلات GitLab الخاصة بنا كلما كان هناك محفز. على الرغم من أن هذا كان مشروعًا بسيطًا، إلا أنه يمكنك البناء على هذه المعلومات لإعداد خطوط أنابيب للمشاريع المعقدة. تظل خطوات إضافة مشروع إلى GitLab وربط GitLab CI runner كما هي. الأشياء التي تتغير هي التعليمات والمراحل في ملف gitlab-ci.yml.

حوسبة سعيدة!