deploy on the cloud and made some refactory on files

q3-cicd/README.md

@@ -1,9 +1,10 @@
-# بناء CI/CD Pipeline على غيمة (GitHub Actions + Ghaymah Container Registry)
+# بناء CI/CD Pipeline على غيمة (GitHub Actions + Docker Registry + Ghaymah CLI)
 
 ## محتويات
 ```
-.github/workflows/workflow.yml   # الـ workflow الكامل
-README.md                        # هذا التوثيق
+q3-cicd/workflow.yml             # نسخة workflow كاملة مرفقة مع إجابة السؤال
+.github/workflows/deploy.yml     # مسودة/نسخة قابلة للنقل إلى GitHub Actions عند الحاجة
+q3-cicd/README.md                # هذا التوثيق
 ```
 
 ---
@@ -18,7 +19,7 @@ build-and-push  ──▶  deploy-staging  ──▶  deploy-production
    + رفع للسجل)         بدون موافقة)          مطلوبة قبل التنفيذ)
 ```
 
-- **build-and-push**: يبني صورة Docker، يشغّلها محليًا داخل الـ runner ويتحقق من `/health` (بوابة جودة أساسية) قبل رفعها فعليًا إلى **Ghaymah Container Registry**.
+- **build-and-push**: يبني صورة Docker، يشغّلها محليًا داخل الـ runner ويتحقق من `/health` (بوابة جودة أساسية) قبل رفعها فعليًا إلى سجل صور OCI. النسخة الحالية من `workflow.yml` تستخدم Docker Hub (`docker.io`) كقيمة افتراضية، ويمكن استبداله بسجل غيمة إن كان متاحًا في الحساب.
 - **deploy-staging**: ينشر الصورة تلقائيًا على بيئة `staging` فور نجاح البناء — بدون تدخل بشري، لأن الهدف من staging هو تحقق سريع ومستمر.
 - **deploy-production**: نفس صورة staging (بدون إعادة بناء) تُنشر على `production`، لكن **الوظيفة لا تبدأ التنفيذ إلا بعد موافقة يدوية** (تفاصيل القسم التالي).
 
@@ -33,7 +34,7 @@ build-and-push  ──▶  deploy-staging  ──▶  deploy-production
 2. أنشئ بيئة باسم `production` (يجب أن يطابق الاسم بالضبط ما هو مكتوب في `environment: name: production` داخل الـ workflow).
 3. فعّل **Required reviewers** وأضف الأشخاص أو الفريق المخوّل بالموافقة على نشر الإنتاج (مثال: قائد الفريق التقني أو مسؤول SRE).
 4. (اختياري لكن موصى به) فعّل **Wait timer** (مثلاً 0-5 دقائق) كطبقة أمان إضافية، و**Deployment branches** لتقييد النشر على فرع `main` فقط.
-5. أضف أسرار الإنتاج (Secrets) الخاصة بهذه البيئة تحديدًا (`GHAYMAH_API_TOKEN` لبيئة production منفصل عن نفس المتغير في staging) — هذا يمنع تسريب صلاحيات الإنتاج حتى لو تم تشغيل job آخر بالخطأ.
+5. أضف أسرار الإنتاج (Secrets) الخاصة بهذه البيئة تحديدًا (`GHAYMAH_Email` و`GHAYMAH_PASSWORD` في النسخة الحالية، أو `GHAYMAH_API_TOKEN` إذا كان الحساب يدعم token مخصصًا للنشر) — هذا يمنع تسريب صلاحيات الإنتاج حتى لو تم تشغيل job آخر بالخطأ.
 
 ### كيف يعمل عمليًا
 عندما يصل تنفيذ الـ workflow إلى job **deploy-production**، يتوقف تلقائيًا في حالة **"Waiting"** ولا تُنفَّذ أي خطوة داخله (بما فيها تسجيل الدخول لـ Ghaymah CLI) حتى يوافق أحد المراجعين المخوّلين من تبويب **Actions** في GitHub. هذا يضمن أن الكود الذي وصل فعليًا إلى staging وتحقق من صحته هو نفسه الذي يُنشر للإنتاج — دون إعادة بناء، ودون فجوة زمنية تسمح بتغييرات غير مراجعة.
@@ -63,23 +64,30 @@ build-and-push  ──▶  deploy-staging  ──▶  deploy-production
 ### أ) التثبيت (داخل الـ workflow أو محليًا)
 ```bash
 curl -fsSL https://cli.ghaymah.systems/install.sh | sh
-ghaymah --version
+gy --version
 ```
 > ملاحظة: عنوان التثبيت وأسماء الأوامر أعلاه مبنية على النمط القياسي لأدوات CLI الخاصة بمنصات الحاويات (deploy/login/logs). يُرجى التأكد من الأمر الدقيق ورابط التثبيت من `docs.ghaymah.cloud` أو console الحساب، حيث إن تفاصيل الواجهة قد تختلف عن الأمثلة هنا.
 
 ### ب) المصادقة (Authentication)
-لا تُستخدم بيانات اعتماد شخصية داخل الـ pipeline أبدًا. بدلًا من ذلك:
-1. يُنشأ **API Token** مخصص لبيئة CI/CD من لوحة تحكم غيمة (Settings → API Tokens أو ما يعادلها)، بصلاحيات محدودة (نشر/سحب صور فقط، وليس صلاحيات إدارية كاملة).
-2. يُخزَّن هذا التوكن كسر (Secret) في GitHub:
-   - `GHAYMAH_REGISTRY_TOKEN` — لتسجيل الدخول لسجل الحاويات (`docker/login-action`).
-   - `GHAYMAH_API_TOKEN` — لتنفيذ أوامر `ghaymah deploy` عبر الـ CLI.
-3. تسجيل الدخول داخل الـ workflow:
+لا تُكتب بيانات الاعتماد داخل ملف الـ workflow. النسخة الحالية تستخدم أسرار GitHub التالية:
+
+- `GHAYMAH_REGISTRY_USER` و`GHAYMAH_REGISTRY_TOKEN` لتسجيل الدخول إلى سجل الصور عبر `docker/login-action`.
+- `GHAYMAH_Email` و`GHAYMAH_PASSWORD` لتسجيل الدخول إلى Ghaymah CLI بالأمر `gy auth login`.
+
+إن كان الحساب يدعم API Token مخصصًا للنشر، فالخيار الأفضل إنتاجيًا هو تخزينه كـ `GHAYMAH_API_TOKEN` بصلاحيات محدودة واستبدال خطوة تسجيل الدخول بـ:
+
    ```bash
-   ghaymah auth login --token "$GHAYMAH_API_TOKEN"
+   gy auth login --token "$GHAYMAH_API_TOKEN"
    ```
 
 ### ج) الربط مع سجل الحاويات (Container Registry)
-تسجيل الدخول لسجل الحاويات يتم عبر الأمر القياسي لـ Docker (متوافق مع أي سجل OCI، بما فيه سجل غيمة):
+تسجيل الدخول لسجل الحاويات يتم عبر الأمر القياسي لـ Docker. في `workflow.yml` القيمة الافتراضية هي Docker Hub:
+```bash
+echo "$GHAYMAH_REGISTRY_TOKEN" | docker login docker.io \
+  --username "$GHAYMAH_REGISTRY_USER" --password-stdin
+```
+
+وإذا تم استخدام سجل غيمة بدل Docker Hub، تصبح الصيغة:
 ```bash
 echo "$GHAYMAH_REGISTRY_TOKEN" | docker login registry.ghaymah.systems \
   --username "$GHAYMAH_REGISTRY_USER" --password-stdin
@@ -88,17 +96,18 @@ echo "$GHAYMAH_REGISTRY_TOKEN" | docker login registry.ghaymah.systems \
 
 ### د) أوامر النشر الأساسية
 ```bash
-# نشر صورة على خدمة معيّنة (staging أو production حسب --env)
-ghaymah deploy --service <service-name> --image <registry>/<namespace>/<image>:<tag> --env <staging|production> --wait
+# إنشاء/تحديد مشروع ثم تهيئة التطبيق وتشغيله
+gy resource project create -s .name=<project-name>
+gy resource app init . -p <project-id>
+gy resource app launch
 
 # متابعة سجلات الخدمة بعد النشر
-ghaymah logs --service <service-name> --follow
+gy resource app logs --follow
 
 # التحقق من حالة الخدمة والنسخ الحالية
-ghaymah status --service <service-name>
+gy resource app get
 
-# التراجع عن نشر فاشل (Rollback) إلى آخر نسخة مستقرة
-ghaymah rollback --service <service-name>
+# ملاحظة: قد تختلف أوامر السجلات/الحالة/rollback الدقيقة حسب إصدار Ghaymah CLI.
 ```
 
 ### هـ) أفضل الممارسات المطبّقة في هذا الـ Pipeline