كيفية تشغيل إجراءات GitHub محليًا باستخدام Act

لقد أحدثت إجراءات GitHub ثورة في كيفية أتمتة المطورين لعمليات العمل داخل مستودعاتهم. من خطوط أنابيب التكامل المستمر والنشر المستمر (CI/CD) إلى أتمتة تصنيف المشاكل وتوليد ملاحظات الإصدار، توفر الإجراءات وسيلة قوية ومتكاملة لإدارة دورة حياة تطوير البرمجيات مباشرة داخل GitHub.

ومع ذلك، قد يبدو تطوير واختبار هذه العمليات مرهقًا في بعض الأحيان. تتضمن الدورة التقليدية:

1. إجراء تغييرات على ملفات سير العمل الخاصة بك (الموجودة عادة في .github/workflows/).
2. تسجيل هذه التغييرات.
3. دفعها إلى مستودع GitHub الخاص بك.
4. انتظار تشغيل جيثب لأداء المهمة وتنفيذها.
5. تحليل السجلات على موقع GitHub لمعرفة ما إذا كانت تغييراتك قد نجحت أو إذا كانت قد أدت إلى أخطاء.

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

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

لماذا تشغيل إجراءات GitHub محليًا باستخدام act؟

إن فوائد دمج act في سير العمل الخاص بك كبيرة:

1. التغذية الراجعة السريعة: هذه هي الميزة الأساسية. بدلاً من دورة التسجيل والدفع والانتظار والتصحيح، يمكنك تشغيل سير العمل الخاص بك على الفور بعد إجراء تغييرات محليًا. احصل على ملاحظات في ثوانٍ أو دقائق، وليس في دقائق أو عشرات الدقائق. هذه السرعة تفجر عملية التطوير والتصحيح لملفات .github/workflows/ الخاصة بك.
2. مشغل مهمات محلي: تستخدم العديد من المشاريع أدوات مثل make وnpm scripts أو سكربتات الغلاف المخصصة لتعريف المهام الشائعة في التطوير (البناء، الاختبار، التحقق، إلخ). يسمح لك act بتجميع هذه المهام. يمكنك تعريف بناءك، اختباراتك، وعملياتك الأخرى كوظائف في إجراءات GitHub، ثم استخدام act لتشغيل هذه الوظائف نفسها محليًا لأغراض التطوير. هذا يقلل من التكرار ويضمن التناسق بين بيئة تطويرك المحلية وخط أنابيب CI/CD الخاصة بك. تقوم بتعريف المهام مرة واحدة في ملفات سير العمل الخاصة بك، وتعمل بشكل متطابق (أو مشابه جدًا) في كل مكان.
3. التطوير دون اتصال: اختبر بناء الجمل الأساسية لشغل العمل والمنطق حتى دون اتصال مستمر بالإنترنت (على الرغم من أن تنزيل الصور الأولية وبعض الإجراءات قد تتطلب الاتصال).
4. توفير التكاليف: بينما توفر GitHub مستوى مجانيًا سخيًا للمستودعات العامة وأسعارًا معقولة للمستودعات الخاصة، يمكن أن يستنزف تشغيل عمليات عمل معقدة أو طويلة بشكل متكرر أثناء التطوير دقائق عداء. الاختبار محليًا يتجنب هذا الاستخدام.
5. قوة التصحيح: غالبًا ما يتضمن تصحيح الإجراءات الفاشلة على GitHub إضافة سجلات إضافية، والدفع، والانتظار. باستخدام act، يمكنك تفقد البيئة المحلية، وتركيب الحجوم، واستخدام تقنيات تصحيح أكثر تقدمًا داخل حاويات Docker التي يقوم بإنشائها.

كيف يعمل act؟

يساعد فهم الآلية وراء act في استخدامه بفعالية وحل القضايا المحتملة. إليك تحليل لعمليته:

1. تحليل سير العمل: عند تنفيذ الأمر act في دليل الجذر لمستودعك، يقوم بفحص دليل .github/workflows/ بحثًا عن ملفات YAML الخاصة بسير العمل.
2. محاكاة حدث التشغيل: بشكل افتراضي، يقوم act بمحاكاة حدث push، ولكن يمكنك تحديد أحداث أخرى مثل pull_request وworkflow_dispatch، إلخ. يحدد أي عمليات العمل والوظائف يجب تشغيلها بناءً على الحدث المحدد وموجهات on: المعرفة في ملفات سير العمل الخاصة بك.
3. تحليل التبعيات: يقوم act بتحليل التبعيات بين الوظائف داخل سير العمل (باستخدام الكلمة الرئيسية needs:) لتحديد ترتيب التنفيذ الصحيح.
4. إدارة صور Docker: لكل وظيفة، يقوم act بتحديد بيئة العداء المحددة (مثل runs-on: ubuntu-latest). ثم يربط هذا بصورة Docker محددة. يستخدم act واجهة برمجة تطبيقات Docker لـ:

• سحب الصور: تحميل صور العدائين المطلوبة وأي صور Docker تستخدمها إجراءات الحاويات (uses: docker://...). بشكل افتراضي، يقوم بسحب الصور في كل عملية تشغيل ما لم يتم تكوين غير ذلك.
• بناء الصور (إذا لزم الأمر): إذا كانت إجراء ما تشير إلى Dockerfile محلي (uses: ./path/to/action)، يمكن لـ act بناء صورة Docker محليًا.

1. تشغيل الحاويات: يستخدم act واجهة برمجة تطبيقات Docker لإنشاء وتشغيل الحاويات لكل خطوة ضمن وظيفة. يقوم بتكوين هذه الحاويات لتقليد بيئة إجراءات GitHub بأكبر قدر ممكن:

• متغيرات البيئة: يتم حقن متغيرات البيئة القياسية لإجراءات GitHub (مثل GITHUB_SHA وGITHUB_REF وGITHUB_REPOSITORY وCI، إلخ).
• نظام الملفات: يتم تركيب كود المستودع في الدليل الخاص بحاوية العمل (/github/workspace). يتم الاحتفاظ بالملفات التي تم إنشاؤها بواسطة الخطوات داخل الحاوية للخطوات التالية.
• الشبكات: عادةً ما يتم تشغيل الحاويات على شبكة جسر Docker، مما يسمح بالتواصل إذا لزم الأمر (على الرغم من أن تفاصيل الشبكات قد تختلف عن بيئة GitHub).

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

بشكل أساسي، يقوم act بتنظيم حاويات Docker المحلية لتكرار تدفق التنفيذ وبيئة سير العمل الخاص بإجراءات GitHub.

المتطلبات الأساسية: تثبيت Docker

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

• تثبيت Docker: اتبع التعليمات الرسمية لنظام التشغيل الخاص بك:
• macOS: Docker Desktop for Mac
• Windows: Docker Desktop for Windows (يتطلب WSL 2 أو Hyper-V)
• Linux: اتبع التعليمات المحددة لتوزيعك (مثل Ubuntu، Fedora، Debian، إلخ). تأكد من إضافة المستخدم الخاص بك إلى مجموعة docker لتشغيل أوامر Docker دون sudo.
• تحقق من Docker: بعد التثبيت، افتح الطرفية الخاصة بك وقم بتشغيل docker run hello-world. هذا الأمر يقوم بتنزيل صورة اختبار صغيرة وتشغيلها في حاوية. إذا تم تشغيلها بنجاح، فإن إعداد Docker الخاص بك جاهز.

تثبيت act

بمجرد تشغيل Docker، يمكنك تثبيت act. هناك عدة طرق للقيام بذلك، اعتمادًا على نظام التشغيل الخاص بك وتفضيلاتك.

1. Homebrew (macOS وLinux)

إذا كنت تستخدم مدير الحزم Homebrew، فإن التثبيت سهل:

brew install act

هذا يقوم بتثبيت أحدث إصدار مستقر. إذا كنت تريد أحدث إصدار تجريبي (والذي قد يتطلب وجود مترجم)، يمكنك استخدام:

brew install act --HEAD

2. إضافة GitHub CLI (macOS وWindows وLinux)

إذا كنت تستخدم بالفعل GitHub CLI (gh)، يمكنك تثبيت act كمجموعة:

gh extension install nektos/gh-act

بعد التثبيت، يمكنك استدعاء act عبر أمر gh:

gh act          # بدلًا من مجرد 'act'
gh act -l
gh act pull_request

3. Chocolatey (Windows)

بالنسبة لمستخدمي مدير الحزم Chocolatey على Windows:

choco install act-cli

(ملاحظة: قد تذكر بعض المصادر act بدلاً من act-cli. تحقق من اسم الحزمة الأحدث على مستودع مجتمع Chocolatey إذا واجهت مشاكل.)

4. Scoop (Windows)

بالنسبة لمستخدمي مدير الحزم Scoop على Windows:

scoop install act

5. WinGet (Windows)

بالنسبة لمستخدمي مدقق الحزم Windows (winget):

winget install nektos.act

6. تثبيت سكربت Linux

يتوفر سكربت مناسب لتوزيعات Linux التي ليس لديها وصول سهل عبر مديري الحزم:

curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

(ملاحظة: دائمًا كن حذرًا عند نقل السكربتات مباشرة إلى sudo. قم بمراجعة محتوى السكربت أولاً إذا كانت لديك مخاوف أمنية.)

7. طرق أخرى (Arch، COPR، MacPorts، Nix)

تتوفر تعليمات التثبيت لمديري الحزم الآخرين مثل pacman (Arch) وCOPR (Fedora) وMacPorts وNix في الوثائق الرسمية لـ act:

التحقق:

بعد التثبيت، افتح نافذة طرفية جديدة وقم بتشغيل:

act --version
# أو إذا كنت تستخدم إضافة gh:
gh act --version

يجب أن يظهر هذا الإصدار المثبت من act، مما يؤكد أن التثبيت كان ناجحًا.

التكوين الأولي: صور العدائين

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

سيتم تقديم خيار مثل هذا:

? الرجاء اختيار الصورة الافتراضية التي تريد استخدامها مع act:

  - Micro: صورة صغيرة مع دعم nodejs (~200MB) docker.io/node:16-buster-slim
  - Medium: صورة Act مع أدوات أساسية (~500MB) ghcr.io/catthehacker/ubuntu:act-latest
  - Large: صورة عداء GitHub Actions (~17GB) ghcr.io/catthehacker/ubuntu:full-latest

الصورة الافتراضية؟ [Medium]:

• Micro: مستند إلى صور Node.js الرسمية المخصصة (مثل node:16-buster-slim أو node:16-bullseye-slim). صغيرة جدًا وسريعة التحميل، ولكن تحتوي فقط على Node.js وأقل المكتبات النظامية. مناسبة إذا كانت إجراءاتك تحتاج فقط إلى Node.js أو تثبت جميع تبعياتها بنفسها.
• Medium: مقدمة من المستخدم catthehacker (مثل catthehacker/ubuntu:act-latest، catthehacker/ubuntu:act-22.04). تشمل هذه الصور المزيد من الأدوات الشائعة الموجودة على عدائين GitHub لكنها لا تزال خفيفة نسبيًا (حوالي 500MB). هذه هي التوصية الافتراضية عادةً لأنها توازن بين الميزات والحجم.
• Large: أيضًا من catthehacker (مثل catthehacker/ubuntu:full-latest، catthehacker/ubuntu:full-22.04). تم إنشاؤها من نفيض نظام الملفات من العدائين المستضافين فعليًا من GitHub وتحتوي على جميع البرامج المثبتة مسبقًا. تقدم أعلى مستوى من التوافق ولكنها كبيرة جدًا (غالبًا أكثر من 17GB)، مما يؤدي إلى أوقات تنزيل طويلة ومعدل استهلاك المساحة على القرص بشكل كبير.

التوصية: ابدأ بـ Medium الصورة. توفر توازنًا جيدًا وتعمل للعديد من الاستخدامات الشائعة. إذا واجهت مشاكل بسبب برامج مفقودة، يمكنك إما تثبيت البرنامج ضمن خطوات سير العمل الخاصة بك أو التبديل إلى استخدام صورة Large لهذا العداء المحدد (المزيد عن هذا لاحقًا).

يحفظ act اختيارك في ملف تكوين (~/.actrc). يمكنك تغيير الافتراضي لاحقًا عن طريق تعديل هذا الملف أو إعادة تشغيل act في دليل يحتاج إلى تكوين.

الاستخدام الأساسي لـ act: تشغيل سير العمل الخاص بك

بمجرد تثبيته وتكوينه، يكون استخدام act بسيطًا نسبيًا. انتقل إلى الدليل الجذري لمشروعك (المحتوي على مجلد .github) في الطرفية الخاصة بك.

1. تشغيل الحدث الافتراضي (push)

أبسط أمر يقوم بتشغيل سير العمل المحفز بواسطة حدث push الافتراضي:

act
# أو
gh act

سيقوم act بتحليل سير العمل الخاصة بك، تحديد الوظائف المحفزة on: push، سحب صور Docker اللازمة (إذا لم تكن مخزنة بالفعل) وتنفيذ الوظائف.

2. قائمة سير العمل والوظائف المتاحة

لرؤية أي سير العمل والوظائف act يتعرف عليها وسيقوم بتشغيلها للحدث الافتراضي:

act -l
# أو
gh act -l

هذا يقوم بالإخراج مثل:

Stage  Job ID        Job name      Workflow name  Workflow file  Events
0      build         Build         CI Pipeline    ci.yaml        push
1      test          Test          CI Pipeline    ci.yaml        push
1      lint          Lint          Code Quality   codeql.yaml    push,pull_request

3. تشغيل وظيفة معينة

إذا كنت ترغب فقط في اختبار وظيفة واحدة من سير العمل، استخدم علامة -j متبوعة بمعرف الوظيفة (من إخراج act -l):

act -j build
# أو
gh act -j build

4. تحفيز حدث معين

غالبًا ما يتم تحفيز سير العمل على أحداث أخرى غير push. يمكنك محاكاة هذه الأحداث من خلال تقديم اسم الحدث كوسيط لـ act:

# محاكاة حدث طلب السحب
act pull_request

# محاكاة حدث workflow_dispatch (تفعيل يدوي)
act workflow_dispatch

# محاكاة حدث الجدولة
act schedule

# محاكاة حدث الإصدار
act release -e event.json # قدّم تفاصيل حمولة الحدث إذا لزم الأمر

سيقوم act فقط بتنفيذ سير العمل والوظائف المكونة للعمل on: الحدث المحدد.

5. تمرير المدخلات لـ workflow_dispatch

يمكن أن تقبل سير العمل المحفزة بواسطة workflow_dispatch المدخلات. يمكنك تقديم هذه باستخدام علامة --input أو -i:

# بافتراض أن سير العمل لديك لديه إدخال باسم 'environment'
act workflow_dispatch --input environment=staging

6. التعامل مع الأسرار

غالبًا ما تعتمد سير العمل وإجراءات GitHub على الأسرار (مثل مفاتيح API أو الرموز). act لا يصل تلقائيًا إلى أسرارك في GitHub. تحتاج إلى تقديمها محليًا.

• مطالبة تفاعلية: استخدم علامة -s. سيطلب act منك إدخال القيمة لكل سر تم تعريفه في سير العمل:

act -s MY_SECRET_TOKEN -s ANOTHER_SECRET

بدلاً من ذلك، فإن act -s سيطلب جميع الأسرار.

• متغيرات البيئة: غالبًا ما يتم تمرير الأسرار كمتغيرات بيئة تُسبَق بـ SECRET_. يمكنك تعريفها في قشرة الخاصة بك قبل تشغيل act:

export SECRET_MY_SECRET_TOKEN="your_value"
act

• ملف الأسرار: أنشئ ملفًا (مثل .secrets) يحتوي على أزواج KEY=VALUE:

MY_SECRET_TOKEN=your_value
ANOTHER_SECRET=another_value

ثم قم بتشغيل act مع علامة --secret-file:

act --secret-file .secrets

(تأكد من إضافة هذا الملف إلى .gitignore لتجنب تسجيل الأسرار!)

7. التعامل مع المتغيرات ومتغيرات البيئة

• متغيرات سير العمل: يمكنك تقديم قيم للمتغيرات المعرفة على مستوى سير العمل (vars: السياق، على الرغم من أن الدعم الكامل لسياق vars في act قد يكون محدودًا) باستخدام علامة --var أو --var-file، مشابهة للأسرار.
• متغيرات البيئة: لتعيين متغيرات بيئة مخصصة لتشغيل سير العمل، استخدم العلامة --env أو --env-file.

act --env NODE_ENV=development --env CUSTOM_FLAG=true
act --env-file .env_vars

إدارة بيئات وصور العدائين

بينما تغطي صور العدائين الافتراضية (Micro، Medium، Large) العديد من السيناريوهات، غالبًا ما تحتاج إلى مزيد من التحكم.

1. قيود الصور الافتراضية

تذكر أن صور العدائين الافتراضية لـ act (خصوصًا Micro وMedium) ليست مطابقة تمامًا للبيئات المقدمة من GitHub. قد تفتقر إلى أدوات أو مكتبات محددة، أو خدمات نظام (مثل systemd) التي تتوقعها سير العمل الخاص بك. توفر الصور الكبيرة دقة أعلى لكن تأتي بخسارة حجم كبيرة.

2. تحديد صور بديلة مع -P

إذا كانت وظيفة تحتاج إلى بيئة أو مجموعة أدوات محددة غير موجودة في الصورة الافتراضية، يمكنك إخبار act باستخدام صورة Docker مختلفة لمنصة معينة باستخدام علامة -P (المنصة).

الصيغة هي -P <platform>=<docker-image>.

• <platform>: التسمية المستخدمة في توجيه runs-on: في سير العمل الخاص بك (مثل ubuntu-latest، ubuntu-22.04، ubuntu-20.04).
• <docker-image>: الاسم الكامل لصورة Docker التي ستستخدمها (مثل node:18، python:3.10-slim، mcr.microsoft.com/devcontainers/base:ubuntu).

أمثلة:

# استخدام الصورة الكبيرة خصيصًا للوظائف التي تعمل على ubuntu-22.04
act -P ubuntu-22.04=ghcr.io/catthehacker/ubuntu:full-22.04

# استخدام إصدار Node.js معين لوظائف ubuntu-latest
act -P ubuntu-latest=node:18-bullseye

# استخدام صورة أكثر شمولاً من nektos/act-environments (كبيرة جدًا!)
# تحذير: nektos/act-environments-ubuntu:18.04 أكبر من 18GB
act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04

# تحديد منصات متعددة إذا كانت سير العمل الخاصة بك تستخدمها
act -P ubuntu-20.04=node:16-buster -P ubuntu-22.04=node:18-bullseye

3. استخدام صور العدائين المحلية (--pull=false)

بشكل افتراضي، يقوم act بمحاولة سحب أحدث إصدار من صورة Docker المحددة في كل مرة يعمل فيها. إذا كنت قد أنشأت صورة عداء مخصصة محليًا أو تريد التأكد من أنك تستخدم الإصدار الدقيق الذي تم تخزينه، يمكنك تعطيل هذا السلوك:

act --pull=false
# أو potentially use offline mode
act --action-offline-mode

هذا يخبر act باستخدام الصورة المتاحة محليًا إذا كانت حاضرة، ومحاولة السحب فقط إذا كانت مفقودة.

4. التشغيل محليًا على المضيف (-self-hosted)

بالنسبة لسير العمل المستهدفة لـ macOS أو Windows (runs-on: macos-latest أو runs-on: windows-latest), إذا كنت تقوم بتشغيل act على هذا النظام التشغيلي المضيف نفسه، يمكنك توجيه act بعدم استخدام حاوية Docker للعداء نفسه. بدلاً من ذلك، ستنفذ الخطوات مباشرة على جهاز المضيف لديك. يمكن أن يكون هذا مفيدًا إذا كانت هناك مشكلات في توافق Docker أو إذا كنت بحاجة إلى الوصول المباشر إلى موارد المضيف.

# تشغيل وظائف macos-latest مباشرة على جهاز Mac الخاص بك
act -P macos-latest=-self-hosted

# تشغيل وظائف windows-latest مباشرة على جهاز Windows الخاص بك
act -P windows-latest=-self-hosted

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

القيود والاعتبارات

بينما يعتبر act مفيدًا للغاية، من المهم أن تكون واعيًا لقيوده:

• ليس نسخة مثالية: يحاكي act بيئة إجراءات GitHub ولكنه ليس مطابقًا. توجد اختلافات في الشبكات، الخدمات النظامية المتاحة (مثل عدم وجود systemd في حاويات Docker بشكل سهل)، موارد الأجهزة المحددة، ومجموعة الأدوات المثبتة مسبقًا (ما لم تستخدم صور العدائين الكبيرة جدًا). قد تتصرف بعض سير العمل، خاصة المعقدة التي تتفاعل بشكل كبير مع نظام التشغيل الأساسي أو ميزات GitHub المحددة، بشكل مختلف في act مقابل GitHub.
• اختلافات السياق: قد تحتوي بعض أجزاء من سياق github على قيم افتراضية أو قيم اختبار عند التشغيل محليًا. يحتاج دائمًا سياق secrets إلى إدخال صريح. قد يكون أيضًا دعم سياق vars محدودًا مقارنة ببيئة GitHub الحية.
• التوازي: عادةً ما يشغل act الوظائف بشكل متسلسل استنادًا إلى تبعيات needs. لا يحاكي تمامًا قدرة GitHub على تشغيل الوظائف المستقلة بالتوازي باستخدام استراتيجيات المصفوفة عبر عدائين متعددين (على الرغم من أن act يدعم تشغيل وظائف المصفوفة، عادةً ما تعمل محليًا بالتسلسل).
• الخدمات المستضافة: قد تعمل ميزات مثل التخزين المؤقت (actions/cache) بشكل مختلف أو تتطلب تكوينًا محددًا محليًا مقارنة بخدمة التخزين المؤقت المدمجة لـ GitHub. يجب أن تعمل حاويات الخدمة المعتمدة في سير العمل، حيث يستخدم act Docker لها أيضًا.
• توفر النظام الأساسي: يمكنك تشغيل الوظائف المستندة إلى Linux فقط داخل Docker على أي مضيف يدعم Docker (Mac وWindows وLinux). لتشغيل وظائف macos-latest، تحتاج إلى act على macOS (أو استخدام علامة -self-hosted على macOS). بالمثل، تتطلب وظائف windows-latest عادةً act على Windows (أو -self-hosted على Windows). بينما يمكن لـ Docker تشغيل حاويات Windows على Windows، يركز act بشكل أساسي على حاويات Linux ودعمه الأكثر استقرارًا يتعلق بهم.

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

الخاتمة

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

من خلال دمج act في سير العمل الخاص بك، تحقق ما يلي:

• حلقات تغذية راجعة أسرع.
• تقليل الاعتماد على الدفع إلى GitHub للاختبار.
• قدرة استخدام تعريفات إجراءاتك كعداد محلي.
• تحسين قدرات التصحيح.

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