بمجرد تشغيل المشروع محلياً، تنقله أربعة أوامر إلى موقع مباشر على استضافة Zinn Digital®: تسجيل الدخول، وربط المشروع بفتحة استضافة، وقراءة الفحص الأولي، ثم الدفع (push). يستعرض هذا المقال كلاً منها، وما يطبعه، والأوامر التي تحتاج إليها بعد ذلك — عمليات إعادة النشر، وسجل النشر، وسجلات البناء.
تسجيل الدخول باستخدام مفتاح API
أنشئ مفتاحاً في لوحة التحكم تحت الإعدادات ← مفاتيح API، ثم:
zinnector login
تتم كتابة المفتاح عند ظهور مطالبة إدخال — ولا يتم قبوله أبداً عبر سطر الأوامر، وبذلك لا يمكن أن ينتهي به الأمر في سجل الأوامر الطرفية (shell history) لديك أو في قائمة العمليات المشغلة. في بيئات التكامل المستمر (CI)، يمكنك تمريره عبر أنبوب (pipe): echo "$ZINN_API_KEY" | zinnector login --profile ci، أو قم بتعيين ZINNECTOR_TOKEN وتخطّ استخدام login تماماً. يتم التحقق من صحة المفتاح قبل تخزينه، ويُخزّن بأذونات الملفات mode 600. يوضح لك الأمر zinnector whoami --scopes المؤسسة التي سجلت الدخول إليها والصلاحيات التي يحملها المفتاح؛ ويتم تصنيف مفتاح البيئة التجريبية (sandbox) وفقاً لذلك.
ربط المشروع بفتحة استضافة
zinnector link # اختر موقعاً من القائمة
zinnector link example.com --repo acme/site --branch main
يكتب الأمر link معرف الموقع داخل ملف zinnector.json، ويقوم بربط مستودع git البعيد للمشروع بالموقع على المنصة ما لم تُمرر الخيار --no-repo، وذلك لتتم عملية النشر عند تنفيذ الدفع (push). احرص على إيداع zinnector.json؛ حيث يتمكن أي زميل يستنسخ المستودع من النشر لاحقاً في المكان نفسه دون الحاجة إلى توجيهه. لا يحتوي هذا الملف على أي معلومات سرية.
قراءة الفحص الأولي
zinnector check
هذا هو الأمر الأساسي الذي صُممت واجهة سطر الأوامر (CLI) من أجله. فهو يقارن مشروعك بفتحة الاستضافة التي توشك على النشر إليها ويطبع كل حالات عدم التطابق — وكل مقارنة لم يتمكن من إجرائها:
- إصدار PHP، مع تصنيف التباين في الإصدارات الرئيسية (major version) على أنه مرتفع لأنه يعطل الموقع بصورة مؤكدة، وتصنيف التباين في الإصدارات الفرعية بدرجة أدنى، لأن تصنيف كل شيء كأمر حرج يجعل المستخدمين يتجاهلون التحذير.
- ما إذا كانت فتحة الاستضافة قادرة على التبديل إلى الإصدار الذي قمت بالبناء عليه، وما إذا كان إصدار PHP الخاص بالفتحة قد تجاوز نهاية فترة الدعم، وما إذا كان الجهاز قد طبق الإصدار بالفعل أم أنه أُخطر بذلك فحسب.
- حجم مشروعك وعدد ملفاته مقابل المساحة المتبقية فعلياً على القرص وحدود مساحة الـ inodes المتاحة على الفتحة — حيث يمكن لشجرة WordPress أن تستنفد سعة الملفات المسموحة بينما تظل أقل بكثير من الحد الأقصى للمساحة التخزينية.
- إصدارات WordPress على كلا الجانبين، وما إذا كانت فتحة الاستضافة قد أنهت التهيئة (provisioning)، وما إذا كان هناك مستودع متصل للدفع إليه.
إنه يوجه تحذيراً؛ ولا يقوم بالحظر مطلقاً. ويمكن تجاوز كل نتيجة تظهر باستخدام zinnector push --force، لأنك تعرف عن موقعك أموراً لا يمكن لأداة الفحص معرفتها. وتُسجل المقارنة التي يتعذر إجراؤها على أنها غير معروفة (unknown)، ولا تُعتبر مجتازة بنجاح أبداً، ويوضح الملخص دائماً عدد هذه الحالات. وافتراضياً، يكون إصدار PHP المحلي هو الإصدار المصرح به في zinnector.json؛ بينما يقوم الخيار --probe بتشغيل بيئة التشغيل المحلية وقياسها بدلاً من ذلك. كما يتيح لك الخيار --strict إنهاء التنفيذ برمز غير صفري عند وجود نتائج غير معروفة أيضاً، وهو ما تحتاجه بوابات التكامل المستمر (CI).
الدفع (Push)
zinnector push
يشغل الأمر push الفحص الأولي، ويدفع التغييرات الخاصة بك، ويطلق عملية النشر ويراقبها حتى اكتمالها، طابعاً الحالة النهائية والإيداع (commit) الذي تم نشره. يقوم الخيار --dry-run بكل العمليات باستثناء النشر الفعلي؛ ويقوم --no-wait بإطلاق عملية النشر والإنهاء فوراً؛ في حين ينشر الخيار --no-git أياً كان ما تمتلكه المنصة بالفعل دون دفع أي تغييرات. وإذا لم يكن الإيداع المنشور هو نفسه الذي تم دفعه للتو، فسيُخطر بذلك.
عندما يطرأ خطأ ما
zinnector deploys example.com # سجل النشر — الحالة، والإيداع، والمُشغِّل، والرسالة
zinnector logs example.com --build # سجل البناء لعملية النشر الأخيرة
zinnector logs example.com --error # سجل أخطاء الموقع
zinnector deploy example.com # إعادة نشر ما هو موجود بالفعل على المنصة
zinnector ai "لماذا تفشل عملية النشر الخاصة بي؟"
يعمل الأمر zinnector ai على المنصة بالارتباط مع حسابك، وبذلك يستطيع الاطلاع على سجل النشر والسجلات نفسها. ومن داخل أي مشروع، فإنه يرسل الهيكل العام للمشروع — أسماء المجلدات، والإصدارات، ومعرف الموقع — ولا يرسل أبداً محتويات الملفات.
مواضيع ذات صلة