ProHoster > بلوق > إدارة > دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

أو كيف تحصل على شارات جميلة لمشروعك في ليلة واحدة من الترميز السهل

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

دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

ستوجهك هذه المقالة خلال الإعداد الأساسي للتكامل المستمر والتسليم لمشروع مكتبة فئة Net Core في GitLab ، ونشر الوثائق على صفحات GitLab ، ودفع الحزم المبنية إلى موجز خاص في Azure DevOps.

تم استخدام VS Code كبيئة تطوير مع الامتداد سير عمل جيت لاب (للتحقق من صحة ملف الإعدادات مباشرة من بيئة التطوير).

مقدمة موجزة

القرص المضغوط - هل هو عندما ضغطت للتو ، وكل شيء قد وقع بالفعل على العميل؟

ما هو CI / CD ولماذا تحتاجه - يمكنك بسهولة البحث في google. اعثر على وثائق كاملة حول تكوين خطوط الأنابيب في GitLab سهل أيضا. سأشرح هنا باختصار ، وإذا أمكن ، دون عيوب ، عملية النظام من منظور عين الطائر:

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

وهكذا لدينا:

  • خط الأنابيب - مجموعة من المهام منظمة في مراحل يمكنك من خلالها إنشاء ، واختبار ، وحزم التعليمات البرمجية ، ونشر بنية مكتملة إلى خدمة سحابية ، وما إلى ذلك ،
  • منصة (مرحلة) - وحدة تنظيم خطوط الأنابيب ، تحتوي على 1+ مهمة ،
  • مهمة (وظيفة) هي وحدة عمل في خط الأنابيب. وهو يتألف من نص (إلزامي) ، وشروط التشغيل ، وإعدادات النشر / التخزين المؤقت للقطع الأثرية ، وأكثر من ذلك بكثير.

وفقًا لذلك ، تنحصر المهمة عند إعداد CI / CD في إنشاء مجموعة من المهام التي تنفذ جميع الإجراءات اللازمة لبناء واختبار ونشر الكود والتحف.

قبل البدء: لماذا؟

  • لماذا جيتلاب؟

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

  • لماذا لا يتم استخدام خطوط أنابيب Azure DevOps؟

لأن هناك الإعداد أساسي - معرفة سطر الأوامر ليست مطلوبة حتى. التكامل مع موفري git الخارجيين - في بضع نقرات ، استيراد مفاتيح SSH لإرسال الالتزامات إلى المستودع - أيضًا ، يتم تكوين خط الأنابيب بسهولة حتى ليس من قالب.

موقف البداية: ما لديك وماذا تريد

لدينا:

  • المستودع في GitLab.

نحن نريد:

  • التجميع والاختبار التلقائي لكل طلب دمج ،
  • بناء حزم لكل طلب دمج والدفع إلى السيد ، بشرط وجود سطر معين في رسالة الالتزام ،
  • إرسال الحزم المدمجة إلى موجز خاص في Azure DevOps ،
  • تجميع التوثيق والنشر في GitLab Pages ،
  • شارات! 11

تندرج المتطلبات الموصوفة عضوياً على نموذج خط الأنابيب التالي:

  • المرحلة 1 - التجميع
    • نقوم بتجميع الكود ، ونشر الملفات الناتجة كقطع أثرية
  • المرحلة الثانية - الاختبار
    • نحصل على القطع الأثرية من مرحلة البناء ، ونجري الاختبارات ، ونجمع بيانات تغطية الكود
  • المرحلة 3 - إرسال
    • المهمة 1 - إنشاء حزمة nuget وإرسالها إلى Azure DevOps
    • المهمة 2 - نقوم بجمع الموقع من xmldoc في الكود المصدري ونشره في صفحات GitLab

لنبدأ!

جمع التكوين

تحضير الحسابات

  1. قم بإنشاء حساب في مايكروسوفت أزور

  2. اذهب إلى أزور ديف أوبس

  3. نقوم بإنشاء مشروع جديد

    1. الاسم - أي
    2. الرؤية - أي
      دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

  4. عند النقر فوق الزر "إنشاء" ، سيتم إنشاء المشروع وإعادة توجيهك إلى صفحته. في هذه الصفحة ، يمكنك تعطيل الميزات غير الضرورية بالانتقال إلى إعدادات المشروع (الارتباط السفلي في القائمة الموجودة على اليسار -> نظرة عامة -> كتلة خدمات Azure DevOps)
    دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

  5. انتقل إلى Atrifacts ، وانقر فوق إنشاء موجز

    1. أدخل اسم المصدر
    2. اختر الرؤية
    3. قم بإلغاء التحديد قم بتضمين الحزم من المصادر العامة المشتركة، بحيث لا يتحول المصدر إلى استنساخ كتلة صلبة
      دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

  6. انقر فوق اتصال للتغذية ، وحدد Visual Studio ، وانسخ المصدر من كتلة إعداد الجهاز
    دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

  7. انتقل إلى إعدادات الحساب ، وحدد رمز الوصول الشخصي
    دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

  8. إنشاء رمز وصول جديد

    1. الاسم - تعسفي
    2. المنظمة - الحالية
    3. صالحة لمدة 1 سنة كحد أقصى
    4. النطاق - التعبئة والتغليف / القراءة والكتابة
      دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

  9. انسخ الرمز الذي تم إنشاؤه - بعد إغلاق النافذة المشروطة ، لن تكون القيمة متاحة

  10. انتقل إلى إعدادات المستودع في GitLab ، وحدد إعدادات CI / CD
    دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

  11. قم بتوسيع كتلة المتغيرات ، أضف واحدة جديدة

    1. الاسم - أي بدون مسافات (سيكون متاحًا في غلاف الأوامر)
    2. القيمة - رمز الوصول من الفقرة 9
    3. حدد متغير القناع
      دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

هذا يكمل التكوين المسبق.

تحضير إطار التكوين

بشكل افتراضي ، يستخدم تكوين CI / CD في GitLab الملف .gitlab-ci.yml من جذر المستودع. يمكنك تعيين مسار عشوائي لهذا الملف في إعدادات المستودع ، ولكن في هذه الحالة ليس ضروريًا.

كما ترى من الامتداد ، يحتوي الملف على تكوين بالتنسيق YAML. توضح الوثائق تفاصيل المفاتيح التي يمكن احتوائها في المستوى الأعلى من التكوين وفي كل مستوى من المستويات المتداخلة.

أولاً ، دعنا نضيف رابطًا إلى صورة عامل الإرساء في ملف التكوين ، حيث سيتم تنفيذ المهام. لهذا نجد صفحة صور Net Core على Docker Hub. في GitHub جيثب: يوجد دليل مفصل حول الصورة التي تختارها لمهام مختلفة. الصورة ذات .Net Core 3.1 مناسبة لنا للبناء ، لذا لا تتردد في إضافة السطر الأول إلى التكوين

image: mcr.microsoft.com/dotnet/core/sdk:3.1

الآن ، عندما يتم تشغيل خط الأنابيب من مستودع صور Microsoft ، سيتم تنزيل الصورة المحددة ، حيث سيتم تنفيذ جميع المهام من التكوين.

الخطوة التالية هي إضافة مرحلة'س. بشكل افتراضي ، يحدد GitLab 5 مراحل:

  • .pre - تم إجراؤها حتى جميع المراحل ،
  • .post - يتم إجراؤها بعد كل المراحل ،
  • build - أولا بعد .pre منصة،
  • test - المرحلة الثانية ،
  • deploy - المرحلة الثالثة.

ومع ذلك ، لا شيء يمنعك من التصريح عنها صراحة. يؤثر الترتيب الذي يتم سرد الخطوات به على الترتيب الذي يتم إجراؤه به. للتأكد من اكتمالها ، دعنا نضيف إلى التكوين:

stages:
  - build
  - test
  - deploy

من أجل تصحيح الأخطاء ، من المنطقي الحصول على معلومات حول البيئة التي يتم فيها تنفيذ المهام. دعنا نضيف مجموعة عالمية من الأوامر التي سيتم تنفيذها قبل كل مهمة باستخدام before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

يبقى إضافة مهمة واحدة على الأقل بحيث يبدأ خط الأنابيب عند إرسال الالتزامات. في الوقت الحالي ، دعنا نضيف مهمة فارغة للتوضيح:

dummy job:
  script:
    - echo ok

نبدأ في التحقق ، نحصل على رسالة مفادها أن كل شيء على ما يرام ، ونلتزم ، وندفع ، وننظر إلى النتائج على الموقع ... ونحصل على خطأ في البرنامج النصي - bash: .PSVersion: command not found. ماهذا الهراء؟

كل شيء منطقي - بشكل افتراضي ، يستخدم المتسابقون (المسؤولون عن تنفيذ البرامج النصية للمهام والتي يوفرها GitLab) bash لتنفيذ الأوامر. يمكنك إصلاح ذلك عن طريق التحديد الصريح في وصف المهمة للعلامات التي يجب أن يمتلكها عداء خط الأنابيب المنفذ:

dummy job on windows:
  script:
    - echo ok
  tags:
    - windows

عظيم! خط الأنابيب قيد التشغيل الآن.

سيلاحظ القارئ اليقظ ، بعد أن كرر الخطوات المشار إليها ، أن المهمة قد اكتملت في المرحلة testرغم أننا لم نحدد المرحلة. كما قد تتخيل test هي الخطوة الافتراضية.

دعنا نواصل إنشاء هيكل التكوين عن طريق إضافة جميع المهام الموضحة أعلاه:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

لقد حصلنا على خط أنابيب لا يعمل بشكل خاص ، ولكنه مع ذلك صحيح.

إعداد المشغلات

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

يمكن تكوين المرشحات بتنسيقين: فقط / باستثناء и القواعد. باختصار، only/except يسمح لك بتكوين عوامل التصفية عن طريق المشغلات (merge_request، على سبيل المثال - تعيين المهمة المطلوب تنفيذها في كل مرة يتم فيها إنشاء طلب سحب وكل مرة يتم فيها إرسال الالتزامات إلى الفرع الذي يمثل المصدر في طلب الدمج) وأسماء الفروع (بما في ذلك استخدام التعبيرات العادية) ؛ rules يسمح لك بتخصيص مجموعة من الشروط ، واختيارياً ، تغيير شرط تنفيذ المهمة بناءً على نجاح المهام السابقة (when في GitLab CI / CD).

لنتذكر مجموعة من المتطلبات - التجميع والاختبار فقط لطلب الدمج والتعبئة والإرسال إلى Azure DevOps - لطلب الدمج والدفع إلى الإصدار الرئيسي وإنشاء الوثائق - لعمليات الدفع إلى المستوى الرئيسي.

أولاً ، لنقم بإعداد مهمة إنشاء التعليمات البرمجية عن طريق إضافة قاعدة لا تنشط إلا عند طلب الدمج:

build job:
  # snip
  only:
    - merge_request

لنقم الآن بإعداد مهمة الحزم لإطلاقها على طلب الدمج وإضافة الالتزامات إلى السيد:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

كما ترى ، كل شيء بسيط ومباشر.

يمكنك أيضًا تعيين المهمة على التنشيط فقط إذا تم إنشاء طلب دمج مع هدف معين أو فرع مصدر:

  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

في ظل الظروف ، يمكنك استخدام المتغيرات المذكورة هنا؛ قواعد rules غير متوافق مع القواعد only/except.

تكوين حفظ القطع الأثرية

أثناء مهمة build job سيكون لدينا أدوات بناء يمكن إعادة استخدامها في المهام اللاحقة. للقيام بذلك ، تحتاج إلى إضافة المسارات إلى تكوين المهمة ، والملفات التي ستحتاج إلى حفظها وإعادة استخدامها في المهام التالية ، إلى المفتاح artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

تدعم المسارات أحرف البدل ، مما يسهل تعيينها بالتأكيد.

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

الآن بعد أن أصبح لدينا إطار تكوين جاهز (ومختبر) ، يمكننا المضي قدمًا في كتابة البرامج النصية بالفعل للمهام.

نكتب النصوص

ربما ، ذات مرة ، في مجرة ​​بعيدة جدًا ، كان بناء المشاريع (بما في ذلك تلك الموجودة على .net) من سطر الأوامر أمرًا مؤلمًا. يمكنك الآن إنشاء المشروع واختباره ونشره في 3 فرق:

dotnet build
dotnet test
dotnet pack

بطبيعة الحال ، هناك بعض الفروق الدقيقة التي بسببها سوف نعقد الأوامر إلى حد ما.

  1. نريد بناء إصدار ، وليس بناء تصحيح ، لذلك نضيف إلى كل أمر -c Release
  2. عند الاختبار ، نريد جمع بيانات تغطية الكود ، لذلك نحتاج إلى تضمين محلل تغطية في مكتبات الاختبار:
    1. أضف الحزمة إلى جميع مكتبات الاختبار coverlet.msbuild: dotnet add package coverlet.msbuild من مجلد المشروع
    2. أضف إلى أمر التشغيل التجريبي /p:CollectCoverage=true
    3. أضف مفتاحًا إلى تكوين مهمة الاختبار للحصول على نتائج التغطية (انظر أدناه)
  3. عند تعبئة الكود في حزم nuget ، اضبط دليل الإخراج للحزم: -o .

جمع بيانات تغطية الكود

بعد إجراء الاختبارات ، يقوم Coverlet بطباعة إحصائيات التشغيل على وحدة التحكم:

Calculating coverage result...
  Generating report 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Module      | Line   | Branch | Method |
+-------------+--------+--------+--------+
| project 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| project 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| project 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Line   | Branch | Method |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Average | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

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

test and cover job:
  # snip
  coverage: /|s*Totals*|s*(d+[,.]d+%)/

هنا نحصل على إحصائيات من خط مع تغطية خطية كاملة.

انشر الحزم والوثائق

تم جدولة كلا الإجراءين للمرحلة الأخيرة من خط الأنابيب - منذ أن اجتاز التجميع والاختبارات ، يمكننا مشاركة تطوراتنا مع العالم.

أولاً ، ضع في اعتبارك النشر إلى مصدر الحزمة:

  1. إذا كان المشروع لا يحتوي على ملف تكوين nuget (nuget.config) ، قم بإنشاء واحدة جديدة: dotnet new nugetconfig

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

  2. دعنا نضيف مصدر حزمة جديد إلى التكوين المحلي: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
    1. name - اسم مصدر محلي ، ليس حرجًا
    2. url - عنوان URL الخاص بالمصدر من مرحلة "إعداد الحسابات" ص 6
    3. organization - اسم المؤسسة في Azure DevOps
    4. gitlab variable - اسم المتغير مع رمز الوصول المضاف إلى GitLab ("تحضير الحسابات" ، ص 11). بطبيعة الحال ، في الشكل $variableName
    5. -StorePasswordInClearText - اختراق لتجاوز خطأ رفض الوصول (أنا لست أول من يخطو على هذا الخليع)
    6. في حالة وجود أخطاء ، قد يكون من المفيد إضافة -verbosity detailed
  3. إرسال الحزمة إلى المصدر: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
    1. نرسل جميع الحزم من الدليل الحالي ، لذلك *.nupkg.
    2. name - من الخطوة أعلاه.
    3. key - أي خط. في Azure DevOps ، في نافذة الاتصال بالتغذية ، يكون المثال دائمًا هو السطر az.
    4. -skipduplicate - عند محاولة إرسال حزمة موجودة بالفعل بدون هذا المفتاح ، سيرجع المصدر خطأ 409 Conflict؛ بالمفتاح ، سيتم تخطي الإرسال.

لنقم الآن بإعداد إنشاء الوثائق:

  1. أولاً ، في المستودع ، في الفرع الرئيسي ، نقوم بتهيئة مشروع docfx. للقيام بذلك ، قم بتشغيل الأمر من الجذر docfx init وضبط بشكل تفاعلي المعلمات الرئيسية لبناء الوثائق. وصف مفصل للحد الأدنى من إعداد المشروع هنا.
    1. عند التكوين ، من المهم تحديد دليل الإخراج ..public - يأخذ GitLab افتراضيًا محتويات المجلد العام في جذر المستودع كمصدر للصفحات. لأن سيكون المشروع موجودًا في مجلد متداخل في المستودع - أضف مخرجات إلى المستوى الأعلى في المسار.
  2. دعنا ندفع التغييرات إلى GitLab.
  3. أضف مهمة إلى تكوين خط الأنابيب pages (كلمة محجوزة لمهام نشر الموقع في صفحات GitLab):
    1. النصي:
      1. nuget install docfx.console -version 2.51.0 - تثبيت docfx ؛ يتم تحديد الإصدار للتأكد من صحة مسارات تثبيت الحزمة.
      2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json - جمع الوثائق
    2. مصنوعات العقدة:

pages:
  # snip
  artifacts:
    paths:
      - public

استطرادا غنائي حول docfx

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

{
  "metadata": [
    {
      "src": [
        {
          "src": "../",
          "files": [
            "**/*.csproj"
          ],
          "exclude":[
            "*.tests*/**"
          ]
        }
      ],
      // --- snip ---
    },
    // --- snip ---
  ],
  // --- snip ---
}

  1. metadata.src.src: "../" - نرتقي بمستوى واحد لأعلى بالنسبة إلى الموقع docfx.json، لأن في الأنماط ، لا يعمل البحث عن شجرة الدليل.
  2. metadata.src.files: ["**/*.csproj"] - نمط عالمي ، نجمع جميع مشاريع C # من جميع الدلائل.
  3. metadata.src.exclude: ["*.tests*/**"] - النمط العام ، واستبعد كل شيء من المجلدات ذات .tests في العنوان

حاصل الجمع

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

نهائي .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)/
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

الحديث عن الشارات

بسببهم ، بعد كل شيء ، بدأ كل شيء!

تتوفر الشارات مع حالات خطوط الأنابيب وتغطية التعليمات البرمجية في GitLab في إعدادات CI / CD في كتلة خطوط أنابيب Gtntral:

دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

لقد أنشأت شارة بها رابط إلى الوثائق الموجودة على المنصة Shields.io - كل شيء واضح تمامًا هناك ، يمكنك إنشاء شارتك الخاصة واستلامها عن طريق الطلب.

![Пример с Shields.io](https://img.shields.io/badge/custom-badge-blue)

دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

تتيح لك Azure DevOps Artifacts أيضًا إنشاء شارات للحزم مع أحدث إصدار. للقيام بذلك ، في المصدر على موقع Azure DevOps ، تحتاج إلى النقر فوق "إنشاء شارة" للحزمة المحددة ونسخ علامة Markdown:

دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

دليل إلى CI / CD في GitLab للمبتدئين (تقريبًا) المطلقين

مضيفا الجمال

تسليط الضوء على أجزاء التكوين العامة

أثناء كتابة التكوين والبحث في الوثائق ، صادفت ميزة مثيرة للاهتمام في YAML - إعادة استخدام الأجزاء.

كما ترى من إعدادات المهمة ، فإنهم جميعًا يحتاجون إلى العلامة windows عند العداء ، ويتم تشغيلها عند إرسال طلب دمج إلى الرئيسي / الذي تم إنشاؤه (باستثناء الوثائق). دعنا نضيف هذا إلى الجزء الذي سنعيد استخدامه:

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

والآن يمكننا إدخال الجزء الذي تم الإعلان عنه مسبقًا في وصف المهمة:

build job:
  <<: *common_tags
  <<: *common_only

يجب أن تبدأ أسماء الأجزاء بنقطة ، حتى لا يتم تفسيرها على أنها مهمة.

إصدار الحزمة

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

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

دعنا نتفق على أنه إذا كانت رسالة الالتزام تحتوي على سطر مثل release (v./ver./version) <version number> (rev./revision <revision>)?، ثم سنأخذ نسخة الحزمة من هذا السطر ، ونكملها بالتاريخ الحالي ونمررها كوسيطة للأمر dotnet pack. في حالة عدم وجود خط ، فإننا ببساطة لن نجمع الحزمة.

البرنامج النصي التالي يحل هذه المشكلة: 

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

إضافة نص إلى مهمة pack and deploy job ومراقبة تجميع الحزم بدقة في وجود سلسلة معينة في رسالة الالتزام.

في المجموع

بعد قضاء حوالي نصف ساعة أو ساعة في كتابة التكوين ، وتصحيح الأخطاء في powerhell المحلي ، وربما عدة عمليات إطلاق غير ناجحة ، حصلنا على تكوين بسيط لأتمتة المهام الروتينية.

بالطبع ، يعد GitLab CI / CD أكثر شمولاً ومتعدد الأوجه مما قد يبدو بعد قراءة هذا الدليل - هذا ليس صحيحًا على الإطلاق. هناك حتى Auto DevOps هوالسماح

اكتشاف تطبيقاتك وإنشاءها واختبارها ونشرها ومراقبتها تلقائيًا

تخطط الخطط الآن لتكوين خط أنابيب لنشر التطبيقات في Azure ، باستخدام Pulumi وتحديد البيئة المستهدفة تلقائيًا ، والتي سيتم تناولها في المقالة التالية.

المصدر: www.habr.com

إضافة تعليق