الـ CI يعيد الفحص بره اللابتوب

المرآة والباب

على جهازك: الحفظ ينسّق، والـ commit يشغّل Husky. ده المرآة. بعد git push، سيرفر يشغّل نفس الفحص على نسخة نظيفة من المستودع. ده الباب.

الـ CI ميستخدمش --write ولا --fix. لو استخدمهم، هيعدّل ملفات على السيرفر ومحدش هياخد التعديل، والفحص هيعدي على شكل مش هو اللي اتدفع. السيرفر يحكم بس.

خط على GitHub Actions

الملف يتحط في .github/workflows/check.yml. الأسماء تتراجع في صفحة كل action لأن الإصدار بيتغير.

name: checkon: [push, pull_request]jobs:  quality:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: actions/setup-node@v4        with:          node-version: 22          cache: npm      - run: npm ci      - run: npx prettier --check .      - run: npx eslint .      - run: npm test

npm ci يثبّت اللي في ملف القفل بالظبط، وميرفعش إصدارات. npm install على السيرفر ممكن يحل شجرة مختلفة عن جهازك. لو الفريق على pnpm، الخطوة المقابلة pnpm install --frozen-lockfile، والكاش يتظبط على pnpm. راجع صفحة setup-node.

npm test لازم يكون موجود في scripts زي ما الفصل اللي فات قال. لو مفيش اختبارات لسه، متعملش خطوة بتنادي أمر مش موجود. إما تضيف اختبار واحد حقيقي، أو تشيل الخطوة لحد ما الأمر يبقى له معنى.

ليه الباب مش اختياري؟

الثلاثة دول يعدّوا المرآة. الـ CI شايف الكوميت اللي على الفرع، مش اللي أنت فاكره على الجهاز. عشان كده الفحص على السيرفر هو اتفاق الفريق، مش إعداد محرر شخصي.

خلّصت الفصل لما

• تفرق فحص السيرفر عن إصلاح الـ hook
• تستخدم npm ci مش install عشان القفل
• تشغّل prettier --check و eslint من غير إصلاح
• تربط npm test بسكربت موجود
• تشرح ليه --no-verify مخلاش الـ CI اختياري