الاختبار بعد كل push أفضل من اكتشاف المشكلة بعد أيام. GitHub Actions يتيح أتمتة workflows داخل المستودع، وتجميع Actions في jobs وsteps لبناء CI أو CD [1]. سنكتب Workflow صغيرًا لا ينشر شيئًا؛ مهمته فقط أن يقول للفريق هل التغيير قابل للدمج.
الملف الأول
name: quality
on:
push:
branches: [main]
pull_request:
branches: [main]
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
cache: npm
- run: npm ci
- run: npm run check
- run: npm testالفكرة الأساسية أن workflow يصف الحدث، ثم job، ثم خطوات قابلة للقراءة. لا تضع أسرارًا في الملف، ولا تمنح workflow صلاحيات كتابة إذا كان يحتاج قراءة فقط.
التثبيت الحتمي
استخدم lockfile وnpm ci أو الأمر المكافئ في مدير الحزم الذي تستخدمه. هذا يمنع أن يحصل جهازان على dependency مختلفة بسبب نطاق إصدار واسع. حدّد نسخة Node في workflow وREADME، وغيّرها bewusst في commit منفصل عندما تريد اختبار إصدار جديد.
التعامل مع الفشل
لا تجعل كل خطوة تبتلع الخطأ. إذا فشل lint، يجب أن يرى الفريق ذلك بوضوح. قسّم الفحوص إلى steps بأسماء مفيدة، واستخدم artifacts فقط عندما تحتاج log أو build نتيجة. كلما كان workflow أبسط، كان تشخيصه أسرع.
قبل إضافة deploy
اجعل CI مستقرًا أولًا، ثم أضف deploy في job منفصل يحتاج environment وصلاحيات محددة. اختبر pull request على preview إن كانت المنصة تدعم ذلك، ولا تضع مفاتيح إنتاج في فرع تجريبي.
مراجع رسمية
هذه الروابط الرسمية هي نقطة الرجوع عند اختلاف إصدار الأداة أو تغيّر سلوك المتصفح.