. التعرف على بنية GitHub Actions Repository Workflow Event Job Step Action Runner Artifact Environment Secret Variable مخطط العلاقات بينها جميعاً. اشرح بالتفصيل الممل جدا واشرح كخبير عالي المستوى للمبتدئين والمحترفين اشرح أدق وأبسط الامور الى اعقدها
الفصل الثالث: البنية الداخلية لـ GitHub Actions
هذه المرحلة هي أهم مرحلة في GitHub Actions بالكامل.
إذا فهمتها جيداً فلن تحتاج إلى حفظ ملفات YAML، بل ستفهمها تلقائياً.
معظم المبتدئيـن يرون ملفاً مثل:
name: Laravel CI
on:
push:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: composer install
- run: php artisan testويشعرون أنه سحر أو لغة جديدة.
لكن في الحقيقة GitHub Actions عبارة عن سلسلة بسيطة جداً:
Repository
↓
Event
↓
Workflow
↓
Job
↓
Step
↓
Action / Command
↓
Runner
↓
Artifactsإذا فهمت هذا المخطط فقد فهمت 70% من GitHub Actions.
أولاً: Repository
ما هو Repository؟
هو المشروع نفسه.
مثلاً لديك مشروع Laravel:
laravel-shopداخل GitHub.
مثال:
laravel-shop
│
├── app
├── routes
├── database
├── docker
├── .github
│ └── workflows
└── composer.jsonهذا يسمى Repository.
لماذا هو مهم؟
لأن جميع GitHub Actions مرتبطة به.
كل شيء يبدأ من Repository.
بدون Repository لا يوجد:
- Workflow
- Actions
- Secrets
- Variables
- Deployments
مثال واقعي
لديك مشروع:
claudsoft-platformكل Push يحدث عليه يمكن أن يشغل GitHub Actions.
ثانياً: Event
ما هو Event؟
الحدث الذي يؤدي إلى تشغيل Workflow.
بمعنى:
شيء حدث داخل GitHub.
أمثلة:
Pushأو:
Pull Requestأو:
Releaseأو:
Tagأو:
Manual Runتشبيه بسيط
تخيل جرس الباب.
الجرس لا يعمل وحده.
يجب أن يضغط أحد عليه.
الضغط = Event
مثال
on:
push:معناه:
“عند حدوث Push”
شغل Workflow.
أمثلة Events شائعة
Push
on:
push:Pull Request
on:
pull_request:Manual
on:
workflow_dispatch:Schedule
on:
schedule:Release
on:
release:ثالثاً: Workflow
ما هو Workflow؟
Workflow هو خطة العمل الكاملة.
تخيل أنك مدير شركة.
عندما يصل طلب جديد:
تقول:
افحص الطلب
↓
راجع البيانات
↓
اصدر الفاتورة
↓
ارسل للعميلهذه الخطة تسمى Workflow.
في GitHub:
Workflow عبارة عن ملف YAML.
مثال:
name: Laravel CIملف Workflow يوجد داخل:
.github/workflowsمثال:
.github/workflows/laravel.ymlWorkflow يحتوي على
Events
Jobs
Stepsرابعاً: Job
ما هو Job؟
الـ Job عبارة عن مهمة كبيرة.
مثال:
Workflow يحتوي:
Test
Build
Deployكل واحدة تعتبر Job.
مثال حقيقي:
jobs:
test:Job أخرى:
jobs:
build:Job أخرى:
jobs:
deploy:الشكل الكامل
Workflow
│
├── Test Job
├── Build Job
└── Deploy Jobلماذا نفصل Jobs؟
لأنها يمكن أن تعمل:
- بالتوازي
- أو بالتسلسل
مثال:
Test
↓
Build
↓
Deployخامساً: Step
ما هو Step؟
الـ Step هو أصغر وحدة عمل.
مثال:
داخل Job الاختبارات.
لدينا:
Install Dependencies
Run Tests
Run PHPStanكل واحدة Step.
مثال:
steps:داخلها:
- run: composer installStep
- run: php artisan testStep
- run: phpstan analyseStep
العلاقة
Workflow
↓
Job
↓
Stepسادساً: Action
هذه نقطة يخطئ فيها معظم المبتدئين.
ما هو Action؟
Action عبارة عن وظيفة جاهزة قام شخص آخر ببنائها.
بدلاً من كتابة عشرات الأوامر.
تستخدم Action جاهزة.
مثال مشهور:
uses: actions/checkout@v4ماذا تفعل؟
تقوم بتحميل المشروع إلى Runner.
بدونها ستحتاج أوامر كثيرة.
مثال آخر:
uses: actions/setup-node@v4يقوم بتثبيت NodeJS.
مثال:
uses: docker/login-action@v3يقوم بتسجيل الدخول إلى Docker Registry.
تشبيه
Action مثل Package في Laravel.
شخص آخر كتبها.
وأنت تعيد استخدامها.
سابعاً: Runner
هذه من أهم المفاهيم.
ما هو Runner؟
Runner هو الجهاز الذي ينفذ الأوامر فعلياً.
عندما تكتب:
run: php artisan testأين يتم التنفيذ؟
على Runner.
GitHub Hosted Runner
GitHub يوفر لك جهازاً مؤقتاً.
مثلاً:
runs-on: ubuntu-latestGitHub ينشئ:
Ubuntu VMمؤقتة.
يشغل الأوامر.
ثم يحذفها.
ما الذي يحدث داخلياً؟
Push
↓
GitHub
↓
Create VM
↓
Execute Workflow
↓
Destroy VMSelf Hosted Runner
هنا أنت توفر الجهاز.
مثلاً:
VPSأو:
Dedicated Serverأو:
Server داخل الشركةثم تربطه بـ GitHub.
متى نستخدم Self Hosted؟
عندما تحتاج:
- Docker سريع
- موارد أكبر
- الوصول للشبكة الداخلية
- Kubernetes خاص
ثامناً: Artifact
ما هو Artifact؟
ملف يتم حفظه بعد انتهاء Job.
مثال:
بعد Build.
ينتج:
app.zipيمكن رفعه كـ Artifact.
مثال آخر:
coverage-report.htmlأو:
build.tar.gzلماذا نستخدمه؟
لنقل الملفات بين Jobs.
مثال:
Build Job
↓
Artifact
↓
Deploy Jobبدلاً من إعادة البناء.
تاسعاً: Environment
هذه نقطة مهمة جداً في الشركات.
ما هو Environment؟
بيئة تشغيل.
مثال:
DevelopmentStagingProductionلماذا؟
لأن كل بيئة لها:
- أسرار مختلفة
- قواعد مختلفة
- موافقات مختلفة
مثال:
environment: productionهنا GitHub يعلم أنك تنشر على Production.
يمكن طلب موافقة قبل النشر.
عاشراً: Secrets
من أخطر المواضيع.
ما هي Secrets؟
بيانات حساسة لا يجب ظهورها.
مثال:
SSH Keyأو:
Database Passwordأو:
API Tokenمثال
بدلاً من:
password: 123456نكتب:
${{ secrets.DB_PASSWORD }}فيظهر فقط أثناء التنفيذ.
ولا يراه أحد.
الحادي عشر: Variables
تشبه Secrets.
لكن ليست حساسة.
مثال:
APP_NAMEأو:
REGIONأو:
DOCKER_IMAGEمثال:
${{ vars.APP_NAME }}الفرق بين Variables و Secrets
Variable
يمكن للجميع رؤيتها.
Secret
مشفرة ومخفية.
العلاقة بين جميع المكونات
الآن دعنا نجمع الصورة كاملة.
مثال عملي Laravel + Docker + Coolify
Repository
│
├── Source Code
│
└── Workflow
│
▼
Event
(Push)
│
▼
Workflow
│
▼
┌────────────┐
│ Test Job │
└────────────┘
│
▼
Steps
│
├── Checkout Action
├── Composer Install
├── PHPUnit
└── PHPStan
│
▼
┌────────────┐
│ Build Job │
└────────────┘
│
▼
Steps
│
├── Docker Build
├── Docker Login
└── Docker Push
│
▼
Artifact
│
▼
┌────────────┐
│ Deploy Job │
└────────────┘
│
▼
Environment
Production
│
▼
Secrets
SSH Keys
│
▼
Runner
│
▼
Serverملخص يجب حفظه
Repository
=
المشروع
Event
=
السبب الذي يبدأ التشغيل
Workflow
=
الخطة الكاملة
Job
=
مهمة كبيرة
Step
=
مهمة صغيرة
Action
=
وظيفة جاهزة
Runner
=
الجهاز الذي ينفذ
Artifact
=
ملفات محفوظة بين Jobs
Environment
=
بيئة التشغيل
Secret
=
بيانات حساسة مخفية
Variable
=
قيم عادية قابلة لإعادة الاستخدامإذا فهمت هذا المخطط جيداً، فإن قراءة أي ملف GitHub Actions YAML لاحقاً ستصبح سهلة جداً، لأنك ستعرف بالضبط أين يقع كل عنصر داخل البنية الكاملة للنظام.