انتقل إلى المحتوى

أسئلة شائعة عن Actions

ملاحظة

تحتاج هذه الميزة إلى تفعيل Actions على الـ repository من Settings ← Advanced Settings ← Enable Repository Actions، وإلى runner متاح يوفّره مدير الخدمة. إن لم يظهر تبويب Actions في الـ repository فالميزة غير متاحة بعد، وكل ما هنا ينطبق «إن كانت مفعّلة».

هذه أجوبة الأسئلة التي تتكرّر عند كتابة أول workflow في ليڤانت غيت (LevantGit)، خصوصًا لمن جاء من GitHub Actions: أيّ سياق تكتب، gitea أم github؟ ومن أين يُحمَّل الـ action؟ وما الأحداث المدعومة؟ ولماذا يبقى الـ workflow run قيد الانتظار؟ أمّا تثبيت الـ runners وإدارتها فمن شأن مدير الخدمة.

هل أكتب ${{ github.xyz }} أم ${{ gitea.xyz }} في ملف الـ workflow؟

الصيغتان تعملان وتعطيان النتيجة نفسها اليوم. Actions مصمَّمة لتكون متوافقة مع GitHub Actions، لذلك يُقبل السياق github. لكن يُستحسن استخدام gitea.xyz في الملفات التي تكتبها خصيصًا لليڤانت غيت: الاسم أوضح لمن يقرأ الملف، وإن أضافت Gitea مستقبلًا حقولًا لا يوفّرها GitHub فستجدها تحت gitea فقط. أما الملفات المنقولة من GitHub فاتركها كما هي.

هل يعمل ملف الـ workflow الموجود في .github/workflows/؟

نعم. يقرأ ليڤانت غيت ملفات الـ workflows من .gitea/workflows/ ومن .github/workflows/ معًا. فإن نفّذت migration لـ repository من GitHub فستعمل workflows غالبًا دون نقل، بشرط أن يوجد runner يحمل الـ label المطلوب في runs-on، وأن لا تعتمد على ميزات GitHub الخاصة (انظر الأسئلة التالية).

من أين يُحمَّل الـ action عندما أكتب uses: actions/checkout@v4؟

عندما تكتب اسمًا قصيرًا مثل actions/checkout@v4 يُحمَّل من GitHub افتراضيًا (https://github.com/actions/checkout). هذا يعني أن عشرات الآلاف من الـ actions في سوق GitHub متاحة لك مباشرة.

وتستطيع تحديد المصدر بعنوان كامل، وهي صياغة إضافية لا توجد في GitHub Actions:

  • uses: https://github.com/xxx/xxx@xxx
  • uses: https://gitea.com/xxx/xxx@xxx
  • uses: https://levantgit.com/xxx/xxx@xxx

انتبه: السابقة https:// (أو http://) ضرورية في هذه الحالة. هكذا تستطيع استخدام action من أي repository يعمل بـ Git، بما في ذلك repositories على ليڤانت غيت.

لماذا لا تعمل كل actions الخاصة بـ GitHub؟

أغلب الـ actions الشائعة (actions/checkout، actions/setup-node، actions/cache، actions/upload-artifact وغيرها) تعمل. لكن بعضها يفشل لأسباب مفهومة:

  • يعتمد على واجهة برمجة GitHub (API): action ينشئ release على GitHub، أو يعلّق على issue عبر GITHUB_TOKEN، يتوقّع خادم GitHub لا ليڤانت غيت. ابحث عن بديل يدعم Gitea أو استخدم curl مع واجهة برمجة ليڤانت غيت و access token تمرّره كـ secret.
  • يستخدم صياغة غير مدعومة بعد: راجع صفحة المقارنة؛ بعض الحقول تُتجاهَل فتتغيّر النتيجة عمّا تتوقّع.
  • يحتاج إلى بيئة معيّنة: actions الـ Docker (runs: using: docker) تحتاج إلى runner يدعم Docker، وهذا يعتمد على إعداد الـ runner الذي يوفّره مدير الخدمة.
  • يفترض حقول سياق خاصة بـ GitHub: بعض حقول github.event تختلف قليلًا. جرّب في repository تجريبي قبل الاعتماد عليها.

ماذا يحدث مع runs-on: [label_a, label_b]؟

الصياغة صحيحة من ناحية القواعد، ومعناها في GitHub «runner يحمل الـ labelين معًا». لكن الـ runner الحالي في Gitea لا يطبّق هذا المعنى تمامًا؛ فهو يحاول مطابقة الـ labels ويستخدم أول تطابق يجده. لتجنّب المفاجآت استخدم label واحدًا: runs-on: ubuntu-latest أو runs-on: [ubuntu-latest].

ما أحداث التشغيل المدعومة؟

كل الأحداث في الجدول التالي مدعومة ومتوافقة مع GitHub. الأحداث الأخرى الموجودة في وثائق GitHub خاصة بـ GitHub وحده.

الحدث أنواع النشاط
create لا ينطبق
delete لا ينطبق
fork لا ينطبق
gollum لا ينطبق
push لا ينطبق
issues opened، edited، closed، reopened، assigned، unassigned، milestoned، demilestoned، labeled، unlabeled
issue_comment created، edited، deleted
pull_request opened، edited، closed، reopened، assigned، unassigned، synchronize، labeled، unlabeled
pull_request_review submitted، edited
pull_request_review_comment created، edited
release published، edited
registry_package published
workflow_dispatch لا ينطبق
workflow_run requested، completed

ملاحظة

في حدث pull_request على GitHub يكون ref هو refs/pull/:prNumber/merge، أي معاينة الـ merge commit. لا يوجد مرجع كهذا في ليڤانت غيت، لذلك يكون ref هو refs/pull/:prNumber/head: رأس branch الـ pull request نفسه، لا معاينة الـ merge.

كيف أشارك actions و workflows قابلة لإعادة الاستخدام من repository خاص؟

افتح Settings ← Actions ← General في الـ repository الخاص الذي يحتوي الـ action، وأضف Collaborative Owners. تستطيع الـ repositories الخاصة لهؤلاء الـ owners بعدها الوصول إلى actions هذا الـ repository و workflows فيه.

هل يعمل concurrency كما في GitHub؟

بحسب وثائق Gitea، يتصرّف ليڤانت غيت كما لو كان concurrency.cancel-in-progress مضبوطًا على true: الـ workflow run الجديد للـ workflow نفسه يُلغي الـ workflow run السابق الذي لا يزال قيد التنفيذ. إن كان هذا السلوك يزعجك (مثلًا في نشر يجب أن يكتمل) فانتبه لعدد الـ pushes المتتالية. التفاصيل في صفحة المقارنة.

لماذا يبقى الـ workflow run «قيد الانتظار» ولا يبدأ؟

غالبًا لا يوجد runner يحمل الـ label المطلوب في runs-on، أو أن الميزة غير متاحة بعد على الخدمة. راجع الـ labels المتاحة من Settings ← Actions ← Runners. وتذكّر أن ليڤانت غيت خدمة مجانية تُقدَّم كما هي دون ضمان توفّر.

ماذا بعد؟

هذه الصفحة مبنية على وثائق Gitea (رخصة MIT) بعد ترجمتها وتبسيطها.