الانتقال إلى المحتوى

الفحوصات المطلوبة في CI

نجحت الفحوصات المطلوبة. لكن اختباراتك لم تعمل.

كيف يمكن لمهام الاختبار المتخطاة شرطيًا أن تستوفي حماية الفرع، وكيف تمنع مهام البوابة الدائمة عمليات الدمج غير المختبرة.

قراءة في 4 دقائقبقلم

فتح تحسين مفيد ثغرة في السياسة

لم تبدأ مهام Unit وE2E إلا بعد إضافة تسمية run-tests. أتاح لنا ذلك تأجيل مجموعات الاختبار المكلفة أثناء إعداد طلب السحب، لكن كان يُفترض أن يشغلها كل دمج. ولم تفرض حماية الفرع ذلك القصد.

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

أبقِ العامل شرطيًا

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

unit-tests:
  if: |
    github.event_name == 'workflow_dispatch' ||
    (github.event.action == 'labeled' && github.event.label.name == 'run-tests') ||
    (github.event.action == 'synchronize' &&
      contains(github.event.pull_request.labels.*.name, 'run-tests'))
  steps:
    - run: pnpm test:unit:coverage

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

افصل عامل التنفيذ عن السياسة

أضفت بوابة صغيرة بعد كل عامل. تعلن العامل في needs، وتعمل بالشرط if: always()، ولا تنجح إلا عندما تكون نتيجة العامل success. وأصبحت أي مجموعة اختبارات متخطاة أو ملغاة أو فاشلة تمنع الدمج برسالة مفيدة.

ci-gate:
  name: CI Gate (Unit)
  runs-on: ubuntu-latest
  needs: [unit-tests]
  if: always()
  steps:
    - name: Check test results
      run: |
        result="${{ needs.unit-tests.result }}"
        if [[ "$result" != "success" ]]; then
          echo "::error::Unit tests did not pass (result: $result)"
          exit 1
        fi
        echo "Unit tests passed"
نتيجة العامل السابق  البوابة المطلوبة
success          نجاح
failure          فشل
cancelled        فشل
skipped          فشل مع رسالة تسمية قابلة للإجراء

أبقِ عوامل التنفيذ المكلفة مشروطة

تقف البوابات أمام مجموعات اختبار فعلية. شملت تغطية الوحدات 73 ملف Jest، وحدود تغطية مفروضة ترتفع تدريجيًا. وشغّل Playwright الاختبارات في Chromium وWebKit باستخدام أربعة عمّال ومحاولتَي إعادة في CI وحالة مصادقة مشتركة.

حصل كل من Unit وE2E على اسم بوابة ثابت. ويمكن لحماية الفرع مواصلة طلب هذين الاسمين حتى لو تغير تنفيذ العامل لاحقًا.

اطلب البوابة، لا عامل التنفيذ

تغيرت حماية الفرع لتطلب CI Gate (Unit) وCI Gate (E2E)، لا العمّال الشرطيين. جعل ذلك عقد الدمج صريحًا: يجب أن تعمل مجموعة الاختبارات المتوقعة بنجاح، أو تنتج فشلًا ظاهرًا يوضح سبب عدم تشغيلها.

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