السابق

التالي

كيف يمكنني استخدام إجراءات GitHub لإنشاء مهام سير عمل التكامل المستمر؟

مكتمل

هنا، تتعرف على إجراءات GitHub وسير العمل المتكامل المستمر.

‏‫ستتعلم كيفية:

• إنشاء سير عمل من قالب
• فهم سِجلات إجراءات GitHub
• اختبار مقابل أهداف متعددة
• مهام الإنشاء والاختبار المنفصلة
• حفظ البيانات الاصطناعية للبناء والوصول إليه
• أتمتة وضع العلامات على العلاقات العامة عند المراجعة

إنشاء سير عمل من قالب

لإنشاء سير عمل، يمكنك البدء باستخدام قالب. يحتوي القالب على وظائف وخطوات شائعة تم تكوينها مسبقا لنوع معين من التنفيذ التلقائي الذي تقوم بتنفيذه. إذا لم تكن مُلِمًا بسير العمل والمهام والخطوات، فعليك دراسة وحدة مهام التطوير التلقائية باستخدام وحدة إجراءات GitHub.

في الصفحة الرئيسية لمستودعك، حدد علامة التبويب Actions ثم حدد New workflow.

في صفحة اختيار سير عمل ، يمكنك الاختيار من بين العديد من القوالب المختلفة. أحد الأمثلة على ذلك هو قالب Node.js ، الذي يقوم بتثبيت نظيف لتبعيات العقدة، وينشئ التعليمات البرمجية المصدر، ويشغل الاختبارات لإصدارات مختلفة من Node. مثال آخر هو قالب حزمة Python، الذي يثبت تبعيات Python، ويدير الاختبارات، بما في ذلك التحليل، عبر إصدارات مختلفة من Python.

في مربع البحث، أدخل Node.js.

في نتائج البحث، في جزء Node.js، حدد تكوين.

ترى سير عمل قالب Node.js الافتراضي هذا، في node.js.yml الملف الذي تم إنشاؤه حديثا.

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

لاحظ on: السِمة. يتم تشغيل سير العمل هذا على دفع إلى المستودع، وعند إجراء طلب سحب مقابل الفرع الرئيسي.

هناك واحد job في سير العمل هذا. دعونا نستعرض ما تفعله.

runs-on:تحدد السِمة أنه بالنسبة إلى نظام التشغيل، يعمل سير العمل على ubuntu-latest. node-version: تحدد السمة أن هناك ثلاث بنيات، واحدة لكل من إصدارات Node 14.x و16.x و18.x. نصف الجزء matrix بعمق لاحقا، عندما نخصم سير العمل.

steps في المهمة، استخدم إجراء إجراءات GitHub Actions/checkout@v3 للحصول على التعليمات البرمجية من المستودع الخاص بك إلى الجهاز الظاهري، والإجراء actions/setup-node@v3 لإعداد الإصدار الصحيح من Node.js. نحدد أننا سنختبر ثلاثة إصدارات من Node.js باستخدام السمة ${{ matrix.node-version }} . تشير هذه السمة إلى المصفوفة التي حددناها مسبقا. cache تحدد السمة مدير حزمة للتخزين المؤقت في الدليل الافتراضي.

أما الجزء الأخير من هذه الخطوة، فهو تنفيذ الأوامر المُستخدَمة من قبل مشاريع Node.js. npm ciيقوم الأمر بتثبيت التبعيات من ملفpackage-lock.jsnpm run build --if-presentوتشغيل برنامج نص بناء (build script) إن كان موجودًا،npm test وتشغيل إطار عمل الاختبار. لاحظ أن هذا القالب يتضمن كلاً من خطوات الإنشاء والاختبار في نفس المهمة.

لمعرفة المزيد عن نظام إدارة الحزم npm، راجع وثائق npm:

• تثبيت npm
• تشغيل npm
• اختبار npm

سجلات الإجراء للبنية

عند تشغيل سير العمل، فإنه يُكوِن سجلاً يتضمن تفاصيل بما حدث وأي أخطاء أو حالات فشل اختبارات.

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

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

تخصيص قوالب سير العمل

في بداية هذه الوحدة النمطية، وصفنا سيناريو تحتاج فيه إلى إعداد CI لفريقك. يعتبر قالب Node.js بداية رائعة، ولكنك تريد تخصيصه ليناسب متطلبات فريقك على نحو أفضل. تريد استهداف إصدارات مختلفة من العُقَد وأنظمة تشغيل مختلفة. تريد أيضا أن تكون خطوات الإنشاء والاختبار وظائف منفصلة.

دعونا نلق نظرة على كيفية تخصيص سير العمل.

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16.x, 18.x]

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

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

test:
  runs-on: ${{ matrix.os }}
  strategy:
    matrix:
      os: [ubuntu-latest, windows-latest]
      node-version: [16.x, 18.x]
  steps:
  - uses: actions/checkout@v3
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - name: npm install, and test
    run: |
      npm install
      npm test
    env:
      CI: true

ما هي البيانات الاصطناعية؟

عندما ينتج سير عمل شيئا آخر غير إدخال السجل، يسمى المنتج أداة. على سبيل المثال، ينتج بناء Node.js حاوية Docker التي يمكن نشرها. يمكن تحميل هذه الأداة، الحاوية، إلى التخزين باستخدام إجراءات الإجراء /upload-artifact وتنزيلها لاحقا من التخزين باستخدام إجراءات الإجراء /download-artifact.

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

تخزين البيانات الاصطناعية

تُخزَّن البيانات الاصطناعية في مساحة التخزين على GitHub. المساحة مجانية للمستودعات العامة وبعض سعتها التخزينية مجاني للمستودعات الخاصة، حسب الحساب. يخزّن GitHub بياناتك الاصطناعية لمدة 90 يومًا.

في قصاصة سير العمل التالية، لاحظ أنه في actions/upload-artifact@main الإجراء هناك سمة path: . قيمة هذه السمة هي المسار لتخزين البيانات الاصطناعية. هنا، نحن تحديد public/ لتحميل كل شيء إلى الدليل. إذا أردنا فقط تحميل ملف واحد، فإننا نستخدم شيئا مثل public/mytext.txt.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

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

test:
    needs: build
    runs-on: ubuntu-latest

في القصاصة البرمجية التالية لسير العمل، نقوم بتنزيل الأداة. الآن يمكن لوظيفة الاختبار استخدام البيانات الاصطناعية للاختبار.

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

لمزيد من المعلومات حول استخدام البيانات الاصطناعية في مهام سير العمل، راجع تخزين بيانات سير العمل كبيانات اصطناعية في وثائق GitHub.

أتمتة المراجعات في GitHub باستخدام مهام سير العمل

حتى الآن، وصفنا بدء سير العمل مع أحداث GitHub مثل الدفع أو طلب السحب. يمكننا أيضا تشغيل سير عمل على جدول زمني، أو على بعض الأحداث خارج GitHub.

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

إجراء آخر يمكن أن نتخذه هو إضافة تسمية إلى طلب السحب. في هذه الحالة، نستخدم الإجراء pullreminders/label-when-approved-action.

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

لاحظ الكتلة التي تسمى env:. هذه الكتلة هي المكان الذي تقوم فيه بتعيين متغيرات البيئة لهذا الإجراء. على سبيل المثال، يمكنك تعيين عدد الموافقين المطلوبين. هنا، واحد أمامك. secrets.GITHUB_TOKEN متغير المصادقة مطلوب لأن الإجراء يجب أن يقوم بإجراء تغييرات على المستودع الخاص بك عن طريق إضافة تسمية. وأخيرًا، يمكنك توفير اسم التسمية لإضافته.

إضافة تسمية يمكن أن تكون حدثاً يبدأ سير عمل آخر، مثل الدمج. نغطي هذا الحدث في الوحدة النمطية التالية حول التسليم المستمر باستخدام GitHub Actions.

متابعة