بناء سير عمل CI / CD - النشر التلقائي لموضوع WordPress باستخدام إجراءات GitHub

نشرت: 2022-11-17

مقدمة

في تطوير الويب الحديث ، غالبًا ما يكون هناك العديد من الخطوات التي يجب عليك القيام بها لإنشاء التعليمات البرمجية الخاصة بك ونشرها في الإنتاج. بالنسبة لموضوع WordPress أو المكون الإضافي ، قد يعني ذلك تثبيت تبعيات Composer و / أو Node.js ، وتجميع CSS ، وتحويل JavaScript ، وتحميل الملفات إلى الخادم الخاص بك.

في هذه المقالة ، سوف نستكشف كيف يمكنك تبسيط عملية نشر WordPress الخاصة بك باستخدام إجراءات GitHub. سننشئ سير عمل GitHub Actions لإنشاء سمة WordPress ونشرها تلقائيًا على موقع Pressidium WordPress الخاص بك.

إذا قمت بالنقر فوق سير العمل فقط ، فقم بالتمرير إلى أسفل هذا المنشور وتصفح في الحال. ومع ذلك ، نشجعك على قراءة المقال بأكمله ، حيث نشرح كيف يعمل كل شيء بالتفصيل!

جدول المحتويات

مقدمة

ابدء

خلق وظيفتك الأولى

بناء ونشر موضوع WordPress الخاص بك

نشر السمة الخاصة بك في بيئات متعددة

وضع سير العمل الكامل معًا

استنتاج

المتطلبات الأساسية

الفهم الأساسي لـ Git (إنشاء مستودع ، والتزام ودفع التعليمات البرمجية ، وإنشاء الفروع ، وما إلى ذلك)
الإلمام بواجهة جيثب

ما هو "النشر" في تطوير الويب؟

النشر في تطوير الويب هو عملية دفع التغييرات إلى بيئة بعيدة ، مما يجعل موقع الويب أو التطبيق متاحًا للاستخدام.

في بعض الأحيان نستخدم مصطلح "النشر" للإشارة إلى مجموعة من الأنشطة - التي تشمل إنشاء الملفات واختبارها ونقلها - بينما نستخدمها في أحيان أخرى بشكل مترادف مع نقل الملفات. في هذه المقالة ، نفرق دائمًا بين البناء والنشر .

هناك العديد من الطرق لدفع ملفات موقع الويب الخاص بك إلى مزود استضافة. في حالتنا ، سنستخدم بروتوكول نقل الملفات الآمن (SFTP) والذي ، كما يوحي الاسم ، هو بروتوكول شبكة لنقل الملفات عبر قناة آمنة ، مثل SSH.

ما هي إجراءات جيثب؟

إجراءات GitHub عبارة عن نظام أساسي للتكامل المستمر والتسليم المستمر (CI / CD) يسمح لك بأتمتة خط أنابيب البناء والنشر.

في الفقرات التالية ، سنستكشف كيفية إنشاء سير عمل GitHub Actions لإنشاء سمة WordPress ونشرها بالاستفادة من موفر استضافة يدعم بيئات التدريج.

التدريج هو بيئة ما قبل الإنتاج للاختبار وهي نسخة طبق الأصل تقريبًا لبيئة الإنتاج. يسعى إلى عكس بيئة الإنتاج الفعلية بأكبر قدر ممكن ، بحيث يمكن اختبار التغييرات هناك قبل تطبيقها على بيئة الإنتاج.

إذا كنت تستخدم Pressidium بالفعل ، فسيتم تضمين بيئات التدريج مجانًا في جميع الخطط. اقرأ مقالة قاعدة المعارف هذه لمزيد من المعلومات.

ما هو سير عمل إجراءات GitHub؟

سير العمل هو عملية تلقائية يتم تشغيلها بواسطة حدث واحد أو أكثر ، وتقوم بتشغيل وظيفة واحدة أو أكثر. تحتوي كل وظيفة على خطوة واحدة أو أكثر. أخيرًا ، يمكن لكل خطوة إما تشغيل برنامج نصي أو إجراء GitHub. يمكن أن يحتوي المستودع على عدة مهام سير عمل تؤدي مهام مختلفة.

هناك العديد من الفوائد لاستخدام سير عمل GitHub Actions.

تقضي وقتًا أقل في القيام بعمل يدوي كثيف العمالة ومتكرر ؛ المزيد من الوقت الذي يضيف قيمة
من الأسهل أن تكون متسقًا عبر البيئات من خلال فرض عملية نشر محددة
يتكامل مع مستودع GitHub الخاص بك ، مما يسمح لك بتتبع التغييرات والوصول إلى سجلات النشر وما إلى ذلك.
يمكن إعادة استخدامه ، مما يعني أنه يمكنك استخدام نفس سير العمل في جميع مستودعاتك

ابدء

لنبدأ بسير العمل الأول الخاص بك عن طريق إنشاء ملف YAML جديد في الدليل .github/workflows/ في مستودع GitHub الخاص بك. سنبدأ بسير عمل بسيط لنشره تلقائيًا في الإنتاج ، لذلك دعونا نطلق على هذا الملف اسم deploy.yml .

 # .github/workflows/deploy.yml name: deploy on: push: branches: # Pushing to the `main` branch # will trigger our workflow - main

نحن نستخدم الكلمة الأساسية on لتحديد الأحداث التي قد تؤدي إلى سير العمل. في هذا المثال ، سيتم تشغيل سير العمل عند الضغط على الفرع main .

ربما لا نحتاج إلى النشر على الإطلاق عند تغيير ملفات معينة ، مثل README.md . يمكننا استخدام on.push.paths-ignore لاستبعاد أنماط مسار الملف.

 name: deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.m

خلق وظيفتك الأولى

يتكون سير العمل من وظيفة واحدة أو أكثر. في هذا المثال ، ستستخدم وظيفة deploy واحدة لتحميل ملفاتك إلى بيئة إنتاج موقع الويب الخاص بك.

 name: deploy on: [...] jobs: deploy: runs-on: ubuntu-latest steps: [...]

يتم تشغيل كل وظيفة في بيئة عداء ، محددة من خلال runs-on . في كتلة YAML أعلاه ، نستخدم ubuntu-latest وهو جهاز ظاهري Ubuntu Linux (VM) ، تستضيفه GitHub مع تطبيق runner وأدوات أخرى مثبتة مسبقًا.

يمكنك إما استخدام عداء مستضاف على GitHub أو استضافة المتسابقين الخاصين بك وتخصيص البيئة المستخدمة لتشغيل المهام. ومع ذلك ، فإن هذا الأخير خارج نطاق هذه المادة.

التحقق من مستودع Git الخاص بك

قبل أن تتمكن من القيام بأي شيء ذي معنى باستخدام التعليمات البرمجية الخاصة بك ، يجب عليك التحقق من المستودع الخاص بك ، حتى يتمكن سير عملك من الوصول إليه. يمكنك استخدام إجراء الخروج لذلك.

 jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout # Checkout our repository under `${GITHUB_WORKSPACE}`, # so our workflow can access it uses: actions/checkout@v3 with: # Fetch the entire Git history fetch-depth: 0

نحدد fetch-depth 0 ، والذي سينتج عنه جلب سجل Git بأكمله. نحتاج إلى هذا لتحميل الملفات التي تم تغييرها فقط في عمليات التشغيل اللاحقة.

إنشاء مستخدم SFTP

لتحميل ملفاتك إلى موفر الاستضافة ، ستحتاج إلى تفاصيل اتصال SFTP (مثل المضيف ومنفذ الشبكة والمسار) ومستخدم SFTP.

في معظم الأوقات ، يمكنك العثور على هذه التفاصيل وإنشاء مستخدم SFTP عبر لوحة معلومات موفر الاستضافة. سيرسل لك بعض مضيفي الويب هذه التفاصيل عبر البريد الإلكتروني.

إذا كنت تستخدم Pressidium بالفعل ، فاتبع الخطوات التالية:

قم بتسجيل الدخول إلى Pressidium Dashboard
حدد خيار قائمة مواقع الويب من الشريط الجانبي للوحة المعلومات
انقر فوق اسم موقع الويب الخاص بك
انتقل إلى علامة التبويب SFTP بالنقر فوق الارتباط الموجود على شريط التنقل
احتفظ بملاحظة بتفاصيل اتصال SFTP
أنشئ مستخدم SFTP جديدًا

لإنشاء مستخدم SFTP جديد:

انقر فوق جديد
حدد البيئة ( الإنتاج أو التدريج )
أدخل اسم مستخدم وكلمة مرور (يوصى باستخدام كلمة مرور قوية وأحرف لاتينية صغيرة وكبيرة مختلطة وأرقام وأحرف خاصة)
احتفظ بملاحظة باسم المستخدم وكلمة المرور اللذين أدخلتهما
انقر فوق إنشاء لإنشاء المستخدم

في الخطوة الثانية ، يجب عليك اختيار البيئة التي تريد النشر إليها. في هذا المثال ، سننشئ مستخدمًا لكل بيئة.

لمزيد من المعلومات حول الوصول إلى موقع Pressidium WordPress الخاص بك عبر SFTP ، راجع مقالة قاعدة المعارف هذه.

تخزين المعلومات الحساسة

يمكنك إدخال تفاصيل اتصال SFTP وبيانات اعتماد مستخدم SFTP مباشرةً في سير عمل إجراءات GitHub. ومع ذلك ، فإن تخزين المعلومات الحساسة في المستودع الخاص بك فكرة سيئة.

يقدم GitHub أسرارًا مشفرة كطريقة لتخزين المعلومات الحساسة في مؤسستك أو مستودعك أو بيئة المستودع.

لإنشاء سر مشفر لمستودع:

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

يجب أن ينتهي بك الأمر بقائمة من الأسرار المشابهة لهذه:

SFTP_HOST اسم مضيف خادم SFTP
SFTP_PORT منفذ خادم SFTP
SFTP_USER اسم المستخدم المراد استخدامه للمصادقة
SFTP_PASS كلمة المرور المراد استخدامها للمصادقة

تحميل الملفات عبر SFTP

لتحميل ملفاتك عبر بروتوكول SFTP ، يمكنك استخدام - - خمنت ذلك - - إجراء GitHub آخر.

هناك العديد من عملاء SFTP وإجراءات GitHub للاختيار من بينها. ذهبنا مع عملنا lftp-mirror-action ، والذي يستخدم lftp تحت غطاء المحرك. أداة لنقل الملفات تدعم SFTP ويمكنها نقل عدة ملفات بالتوازي.

 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

يعد تكوين مدخلات إجراء lftp-mirror-action بسيطًا جدًا:

يمكن الوصول إلى تفاصيل اتصال SFTP وبيانات اعتماد مستخدم SFTP من خلال سياق secrets (مثل ${{ secrets.SFTP_HOST }} )
يعد remoteDir المسار إلى دليل السمة الخاصة بك
سيعمل خيار '--verbose' على تمكين الإخراج المطول ، والذي سيسجل جميع عمليات نقل الملفات (مفيد لاستكشاف الأخطاء وإصلاحها)

في Pressidium ، يتم تنسيق المسارات على النحو التالي:

YOUR_INSTALLATION_NAME-www/ جذر لبيئة الإنتاج
YOUR_INSTALLATION_NAME-dev-www/ جذر لبيئة التدريج

حيث YOUR_INSTALLATION_NAME هو اسم التثبيت الخاص بك. لاحظ أن مالك الحساب لديه حساب SFTP ، يتم عرضه كحساب "رئيسي" ، والذي يمكنه الوصول إلى جميع مواقع الويب ، لذلك ستختلف مساراتهم عن تلك المذكورة أعلاه. يوصى بتجنب استخدام هذا الحساب وإنشاء حساب منفصل بدلاً من ذلك لكل موقع ويب تريد الوصول إليه.

اختياريًا ، يمكنك إنشاء ملف .lftp_ignore في المستودع الخاص بك ، بما في ذلك أي أنماط ملفات ترغب في استبعادها من النشر.

فيما يلي مثال لما قد يبدو عليه هذا:

 ## Directories to ignore .vscode/** .env.** .git/ .github/ ## Files to ignore .gitignore package.json package-lock.json composer.json composer.lock

ضع كل شيء معا

 name: deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

هذا هو! يمكن لسير عملك الآن نشر قالب WordPress الخاص بك تلقائيًا.

بناء ونشر موضوع WordPress الخاص بك

حتى الآن ، أبقينا الأمور بسيطة من خلال التركيز فقط على نشر ملفاتك مع تجاهل أي تبعيات قد تحتاج إلى تثبيتها ، وبناء البرامج النصية التي قد تحتاج إلى تشغيلها ، وما إلى ذلك.

كإعداد مثال ، سنستخدم مستودع GitHub بفرعين:

الفرع main المستقر والجاهز للإنتاج ، والذي سيتم نشره في بيئة الإنتاج
فرع preview الذي لم يتم اختباره ، والذي يعمل كفرع تكامل للميزات وسيتم نشره في بيئة مرحلية

حان الوقت لتقديم وظيفة build وإعادة تسمية سير العمل لدينا build-deploy ، حيث سيكون مسؤولاً عن بناء ونشر الكود الخاص بنا.

 name: build-deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: [...] deploy: [...]

التحقق من مستودع Git الخاص بك

يتم تشغيل كل وظيفة في نسخة جديدة من صورة عداء ، لذلك عليك التحقق من مستودع GitHub الخاص بك مرة أخرى في مهمة build .

 build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3

لا يتعين عليك إحضار محفوظات Git بالكامل في وظيفة الإنشاء ، حتى تتمكن من الالتزام بالقيم الافتراضية لمدخلات الإجراء.

تثبيت التبعيات

تستخدم بعض السمات حزم ومكتبات تابعة لجهات خارجية. إذا كان المظهر الخاص بك يتطلب أي حزم PHP و / أو JavaScript ، فقد ترغب في استخدام مدير الحزم ، مثل Composer أو npm أو yarn.

من أجل هذا المثال ، سنفترض أنك بحاجة إلى تثبيت تبعيتي Composer و Node.js. لحسن الحظ بالنسبة لنا ، هناك إجراءات جاهزة للاستخدام من أجل ذلك.

 steps: - name: Checkout uses: actions/checkout@v3 - name: Install Composer dependencies uses: php-actions/composer@v6 - name: Install Node.js LTS uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install

سيعمل إجراء composer على تشغيل composer install افتراضيًا ، لذلك لن تضطر إلى تكوين أي من معلمات الإدخال الخاصة به.

بالنسبة لإجراء الإعداد - عقدة ، قمنا بتعيين قيم مخصصة لإصدار node-version ومدخلات cache لتحديد أننا نريد:

احصل على إصدار الدعم طويل المدى (أو LTS) من Node.js
تخزين أي تبعيات يتم جلبها عبر مدير حزمة الغزل

بعد ذلك ، ستقوم الخطوة التالية بتشغيل yarn install تبعيات Node.js. تذكر ، يمكن أن تقوم الخطوة بتشغيل نص أو إجراء GitHub.

لاحظ أن التخزين المؤقت يمكن أن يؤدي إلى تسريع سير عملك بشكل كبير. سيؤدي تنزيل التبعيات في كل مرة يتم فيها تشغيل سير العمل إلى وقت تشغيل أطول. يمكنك تخزين التبعيات لوظيفة ما مؤقتًا باستخدام إجراء ذاكرة التخزين المؤقت (وهو ما يفعله إجراء setup-node أيضًا تحت الغطاء) ، مما يؤدي إلى تسريع الوقت المستغرق لإعادة إنشاء الملفات.

تشغيل عملية البناء الخاصة بك

مرة أخرى ، سنفترض أنك بحاجة إلى تنفيذ عملية "الإنشاء" - فقد تحتاج إلى تشغيل معالج أولي لتجميع أوراق الأنماط الخاصة بك ، وترجمة البرامج النصية ES6 + ، وما إلى ذلك. وهذا يعني عادةً أنك قمت بتعريف برنامج نصي build في ملف package.json .

لذلك ، ستحتاج إلى خطوة أخرى لتشغيل عملية البناء هذه.

 - name: Build theme run: yarn run build

إذا كنت بحاجة إلى تشغيل برنامج نصي مختلف للفروع main وفروع preview (على سبيل المثال ، build للفرع main ، والتشغيل staging preview ) ، فيمكنك القيام بذلك على النحو التالي:

 - name: Build theme run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi

أخيرًا ، نظرًا لأن كل وظيفة تعمل في مثيل جديد لصورة عداء ، فإن الوظائف في سير عملك معزولة تمامًا. هذا يعني أنك بحاجة إلى طريقة لتخزين الملفات التي أنشأتها للتو مؤقتًا ، بحيث يمكن الوصول إليها من خلال مهمة deploy . أدخل القطع الأثرية .

الآثار

تتيح لك العناصر الأثرية الاحتفاظ بالبيانات بعد اكتمال المهمة ، بحيث يمكنك مشاركة البيانات بين الوظائف في سير العمل.

دعنا نقدم خطوة إضافية لوظيفة build الخاصة بك لاستمرار البيانات التي تم إنتاجها أثناء خطوات الإنشاء مع فترة استبقاء ليوم واحد ، باستخدام إجراء Upload-Artifact . سنفترض أن Composer يقوم بتثبيت تبعياته في الدليل vendor/ ، وأن البرنامج النصي build يقوم بتصدير الملفات إلى مجلد dist/ .

 - name: Upload artifact uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1

اعتمادًا على حجم المستودع الخاص بك وعدد مرات الدفع ، قد ترغب في إلقاء نظرة على حدود الاستخدام والفواتير والإدارة في GitHub.

في وقت كتابة هذا التقرير ، بشكل افتراضي ، تقوم GitHub بتخزين السجلات والتحف لمدة 90 يومًا وتوفر 500 ميجابايت من التخزين على خطة "GitHub Free".

تشغيل الوظائف بالتتابع

يتكون سير العمل من وظيفة واحدة أو أكثر ، والتي تعمل بشكل متوازٍ بشكل افتراضي. في حالتنا ، يتعين علينا بناء موضوعنا قبل أن نتمكن من نشره. لتشغيل build deploy المهام بشكل تسلسلي ، عليك تحديد التبعية باستخدام jobs.<job_id>.needs . تحتاج إلى كلمة أساسية.

 deploy: runs-on: ubuntu-latest needs: build

في المثال أدناه ، نذكر أن مهمة build يجب أن تكتمل بنجاح قبل تشغيل مهمة deploy .

 name: build-deploy on: [...] jobs: build: runs-on: ubuntu-latest steps: [...] deploy: runs-on: ubuntu-latest needs: build steps: [...]

تنزيل الأداة

قبل أن تتمكن من تحميل أي بيانات تم إنشاؤها أثناء خطوات الإنشاء ، يجب عليك تنزيلها. دعنا نعيد النظر في مهمة deploy خطوة إضافية.

 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: .

يمكنك استخدام إجراء تنزيل -Arti بشكل مشابه لـ Upload-Artifact . تأكد من تحديد نفس الاسم - my-theme-build ، في هذا المثال - لكلا الإجراءين.

ضع كل شيء معا

 name: build-deploy on: push: branches: - main paths-ignore: - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Install Composer dependencies uses: php-actions/composer@v6 - name: Install Node.js LTS uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install - name: Build theme run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi - name: Upload artifact uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1 deploy: runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/checkout@v3 with: fetch-depth: 0 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: . - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ secrets.SFTP_USER }} pass: ${{ secrets.SFTP_PASS }} remoteDir: '/demo-www/wp-content/themes/my-theme' options: '--verbose'

الآن لديك سير عمل GitHub Actions الذي يمكنه إنشاء التعليمات البرمجية ونشرها تلقائيًا في الإنتاج عندما تضغط على الفرع main ! ومع ذلك ، في بداية هذه المقالة ، وصفنا سير عمل يمكن نشره في كل من بيئات الإنتاج والتشغيل المرحلي ، اعتمادًا على الفرع الذي تدفع إليه. إذا كنت لا تزال مستعدًا لذلك ، فاستمر في القراءة!

نشر السمة الخاصة بك في بيئات متعددة

قد يتطلب النشر في بيئات متعددة تغيير سير العمل قليلاً. على سبيل المثال ، غالبًا ما يوصى بوجود مستخدمين منفصلين لبروتوكول SFTP لكل بيئة ويعتبر من أفضل الممارسات. في Pressidium ، يختلف مستخدمو SFTP في بيئات الإنتاج والتدريج لموقع الويب.

لذلك ، دعونا ننشئ أسرارًا مختلفة لاسم المستخدم / كلمة المرور لكل مستخدم. هذا يعني أن قائمتنا المحدثة للأسرار المشفرة يجب أن تبدو كما يلي:

SFTP_HOST
SFTP_PORT
SFTP_PROD_USER
SFTP_PROD_PASS
SFTP_STAG_USER
SFTP_STAG_PASS

قد تضطر أيضًا إلى تحديث المضيف ومنفذ الشبكة. رغم ذلك ، في هذه الحالة ، ليست هناك حاجة لتغييرها ، لأنها متطابقة في كلتا البيئتين.

تحديد متغيرات البيئة

متغير البيئة هو متغير ، يتكون من زوج اسم / قيمة ، وهو جزء من البيئة التي يتم فيها تشغيل العملية.

في سير عمل GitHub Actions ، يمكنك استخدام الكلمة الأساسية env لتعيين متغير بيئة مخصص يتم تحديده من أجل:

سير العمل بأكمله ، باستخدام البيئة env في المستوى الأعلى لسير العمل
وظيفة ضمن سير عمل ، باستخدام البيئة env على مستوى تلك الوظيفة
خطوة محددة داخل الوظيفة ، باستخدام البيئة env على مستوى تلك الخطوة

يمكنك أيضًا إلحاق متغيرات البيئة بـ $GITHUB_ENV ، مما يجعل هذا المتغير متاحًا لأي خطوات لاحقة في مهمة سير العمل.

كما ترى ، هناك عدة طرق لبناء مهام سير العمل الخاصة بك. لذلك ، لا تتردد في استخدام أيهما أكثر منطقية بالنسبة لك.

في حالتنا ، قمنا بتعيين متغيرات البيئة في خطوة من الوظيفة لتخزين القيم مؤقتًا والوصول إليها من خطوة أخرى يتم تشغيلها لاحقًا في سير العمل لدينا. سنلحق متغيرات البيئة بـ $GITHUB_ENV ضمن الخطوات التي يتم تشغيلها لأحداث push إلى فروع معينة لعرض كيف يمكنك تعيين متغيراتك المخصصة بشكل مشروط.

 - name: Set environment variables (main) if: github.ref == 'refs/heads/main' run: | echo "SFTP_USER=${{ secrets.SFTP_PROD_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_PROD_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set environment variables (preview) if: github.ref == 'refs/heads/preview' run: | echo "SFTP_USER=${{ secrets.SFTP_STAG_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_STAG_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-dev-www/wp-content/themes/my-theme" >> $GITHUB_ENV

نستخدم الكلمة الأساسية if لقصر كل خطوة على فرع معين. بهذه الطريقة ، سيتم تشغيل متغيرات البيئة المحددة (الرئيسي) فقط إذا تم دفع التغييرات إلى الفرع main .

قد تختلف أيضًا $DEPLOY_PATH لكل بيئة.

على سبيل المثال ، في Pressidium:

تتبع مسارات بيئات الإنتاج تنسيق /<WEBSITE_NAME>-www/
تتبع مسارات بيئات التدريج تنسيق /<WEBSITE_NAME>-dev-www/

ضبط النواتج

نود استخدام متغيرات البيئة التي قمنا بتعيينها للتو كمدخلات إلى إجراء GitHub الذي سينقل الملفات عبر SFTP.

لسوء الحظ ، في الوقت الحالي ، لا يبدو أنه من الممكن الإشارة إلى متغيرات البيئة كمدخلات لإجراء GitHub. يمكنك التغلب على ذلك من خلال إنشاء خطوة إضافية ستخرج القيم التي ستحتاج إلى استخدامها كمدخلات لاحقًا.

 - name: Set outputs # Workaround to reference environment variables as inputs # using step outputs, since we can't pass environment # variables as inputs at the moment. id: sftp_details run: | echo "user=${SFTP_USER}" >> $GITHUB_OUTPUT echo "pass=${SFTP_PASS}" >> $GITHUB_OUTPUT echo "deploy_path=${DEPLOY_PATH}" >> $GITHUB_OUTPUT

لديك الآن مخرجات user ، و pass ، و deploy_path لخطوة sftp_details ، والتي يمكنك استخدامها للإشارة إلى هذه القيم كمدخلات لخطوتك التالية.

تحميل الملفات إلى بيئات مختلفة

تحميل الملفات عبر SFTP يشبه إلى حد كبير ما كان عليه من قبل ، ولكن بدلاً من الرجوع إلى سياق secrets وترميز remoteDir ، ستستخدم مخرجات الخطوة السابقة.

 - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ steps.sftp_details.outputs.user }} pass: ${{ steps.sftp_details.outputs.pass }} remoteDir: ${{ steps.sftp_details.outputs.deploy_path }} options: '--verbose'

استخدم ${{ steps.<step_id>.outputs.<output_name> }} للوصول إلى ناتج الخطوة. على سبيل المثال ، ${{ steps.sftp_details.outputs.user }} للوصول إلى إخراج user لخطوة sftp_details .

أخيرًا! يمكن الآن لسير العمل الخاص بك بناء ونشر قالب WordPress الخاص بك في كل من بيئات الإنتاج والتشغيل .

وضع سير العمل الكامل معًا

 name: build-deploy on: push: branches: # Pushing to any of the following # branches will trigger our workflow - main - preview paths-ignore: # When all the path names match patterns in `paths-ignore` # the workflow will not run. We don't want to do anything # if we have changed *only* (some of) these files - 'bin/**' - 'README.md' jobs: build: runs-on: ubuntu-latest steps: - name: Checkout # Checkout our repository under `${GITHUB_WORKSPACE}`, # so our workflow can access it uses: actions/checkout@v3 - name: Install Composer dependencies # This will run `composer install` # since that's its default command uses: php-actions/composer@v6 - name: Install Node.js LTS # We use the LTS version of Node.js # and cache packages installed via yarn uses: actions/setup-node@v3 with: node-version: 'lts/*' cache: 'yarn' - name: Install Node.js dependencies run: yarn install - name: Build theme # Run the `build` script for production, # and the `staging` script for staging run: | if [[ "${{ github.base_ref }}" == "main" || "${{ github.ref }}" == "refs/heads/main" ]]; then yarn run build else yarn run staging fi - name: Upload artifact # Persist data produced during the build steps # with a retention period of 1 day uses: actions/upload-artifact@v3 with: name: my-theme-build path: | dist/ vendor/ retention-days: 1 deploy: runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/checkout@v3 with: # Fetch the entire Git history fetch-depth: 0 - name: Download artifact uses: actions/download-artifact@v3 with: name: my-theme-build path: . - name: Set environment variables (main) if: github.ref == 'refs/heads/main' run: | echo "SFTP_USER=${{ secrets.SFTP_PROD_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_PROD_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set environment variables (preview) if: github.ref == 'refs/heads/preview' run: | echo "SFTP_USER=${{ secrets.SFTP_STAG_USER }}" >> $GITHUB_ENV echo "SFTP_PASS=${{ secrets.SFTP_STAG_PASS }}" >> $GITHUB_ENV echo "DEPLOY_PATH=/demo-dev-www/wp-content/themes/my-theme" >> $GITHUB_ENV - name: Set outputs # Workaround to reference environment variables as inputs # using step outputs, since we can't pass environment # variables as inputs at the moment. id: sftp_details run: | echo "user=${SFTP_USER}" >> $GITHUB_OUTPUT echo "pass=${SFTP_PASS}" >> $GITHUB_OUTPUT echo "deploy_path=${DEPLOY_PATH}" >> $GITHUB_OUTPUT - name: Deploy via SFTP uses: pressidium/lftp-mirror-action@v1 with: host: ${{ secrets.SFTP_HOST }} port: ${{ secrets.SFTP_PORT }} user: ${{ steps.sftp_details.outputs.user }} pass: ${{ steps.sftp_details.outputs.pass }} remoteDir: ${{ steps.sftp_details.outputs.deploy_path }} options: '--verbose'

يمكنك أيضًا العثور على مثال لموضوع WordPress وسير عمل GitHub Actions على مستودع GitHub هذا.

استنتاج

ها أنت ذا! GitHub Actions هي أداة قوية تجعل من السهل أتمتة إنشاء ونشر سمات WordPress والمكونات الإضافية.

لقد خدشنا بالكاد سطح ما يمكنك تحقيقه من خلال إجراءات GitHub. يمكن أن تكون خطواتك التالية هي تشغيل أي اختبارات قد تكون لديك تلقائيًا ، أو فتح المشكلات أو الإخطار على Slack عند الانتهاء من النشر ، والقائمة تطول.

ألق نظرة على GitHub Marketplace حيث وقت كتابة هذا التقرير يمكنك العثور على أكثر من 15000 إجراء لاستخدامها في مهام سير عمل GitHub Actions.

فما تنتظرون؟

ألق نظرة على سير عمل هذا المستودع على GitHub
قم بإنشاء ملف YAML جديد ضمن .github/workflows/ في مستودع Git الخاص بك
استمتع بالبنيات وعمليات النشر المؤتمتة

عمليات نشر سعيدة!