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

مقارنة مع GitHub Actions

ملاحظة

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

Actions في ليڤانت غيت (LevantGit) متوافقة مع GitHub Actions في أغلب الصياغة، لا في كلها. تجد هنا الفروق مجموعة: ميزات تزيد مثل العناوين المطلقة للـ actions، وحقول تُتجاهَل مثل concurrency وtimeout-minutes، وميزات ناقصة، وسلوك مختلف في التزامن وتحميل الـ actions. اقرأها قبل نقل workflow معقّد من GitHub.

ملاحظة

هذه القائمة منقولة من وثائق Gitea، وتتطوّر مع كل إصدار (ليڤانت غيت يعمل على Gitea 1.25). إن كان حقل معيّن مهمًّا لك فجرّبه في repository تجريبي بدلًا من الاعتماد على القائمة وحدها.

ميزات إضافية لا توجد في GitHub

عناوين مطلقة للـ actions

تستطيع استدعاء action من أي repository يعمل بـ Git بعنوان كامل، مثل uses: https://github.com/actions/checkout@v4 أو uses: https://levantgit.com/owner/repo@branch. GitHub لا يقبل إلا actions من GitHub نفسه.

actions مكتوبة بلغة Go

يمكن كتابة الـ actions بلغة Go إضافةً إلى JavaScript و Docker. انظر Creating Go Actions في مدونة Gitea.

صياغة الجدولة المختصرة

في on: schedule تُقبل الصيغ غير القياسية @yearly و@monthly و@weekly و@daily و@hourly إلى جانب صيغة cron العادية. GitHub لا يدعمها.

صياغة غير مدعومة (تُتجاهَل حاليًا)

الحقول التالية صحيحة من ناحية القواعد ولن تُسبّب خطأ، لكن ليڤانت غيت يتجاهلها اليوم. احذر: workflow يعتمد عليها سيعمل بنتيجة مختلفة عمّا تتوقّع.

الحقل الغرض في GitHub الحال في ليڤانت غيت
concurrency تشغيل job واحد في كل مرة لمجموعة معيّنة يُتجاهَل (انظر «سلوك مختلف» أدناه)
permissions وjobs.<job_id>.permissions تحديد صلاحيات token الـ job يُتجاهَل
jobs.<job_id>.timeout-minutes مهلة قصوى للـ job يُتجاهَل
jobs.<job_id>.continue-on-error السماح بفشل الـ job دون فشل الـ workflow يُتجاهَل
jobs.<job_id>.environment ربط الـ job ببيئة نشر يُتجاهَل
runs-on المركّب مجموعات labels وتعبيرات يُدعم فقط runs-on: xyz أو runs-on: [xyz]

ميزات ناقصة

النشر إلى package registry بـ token الـ job

على GitHub يستطيع GITHUB_TOKEN داخل الـ job النشر إلى package registry الخاص بالـ repository (رفع container image مثلًا) عبر نطاق packages. في ليڤانت غيت لا يملك GITEA_TOKEN هذه الصلاحية بعد. الحل المؤقت: أنشئ access token شخصيًا بالنطاق المناسب، وخزّنه كـ secret، ومرّره إلى الـ step. انظر الـ issue المتابِع.

مطابِقات المشاكل (Problem Matchers)

آلية فحص مخرجات الـ action بتعبير نمطي وإبراز النتائج في الواجهة. انظر Problem matchers. تُتجاهَل حاليًا.

تعليقات الأخطاء (annotations)

أوامر الـ workflow التي تنشئ تعليق خطأ في الواجهة تُتجاهَل حاليًا؛ يظهر النص في السجل فقط.

التعبيرات

من دوال التعبيرات الخاصة بالحالة، تذكر وثائق Gitea دعم always() فقط. جرّب غيرها قبل الاعتماد عليها.

فروق في الواجهة

  • Pre/Post steps: لا قسم خاصًا بها في سجل الـ job؛ تظهر مدمجة.
  • service steps (services): لا قسم خاصًا بها في سجل الـ job أيضًا.

سلوك مختلف

التزامن (concurrency)

يتصرّف ليڤانت غيت كما لو كان concurrency.cancel-in-progress مضبوطًا على true: الـ workflow run الجديد للـ workflow نفسه يُلغي الـ workflow run السابق الذي لا يزال قيد التنفيذ. انتبه لذلك في workflows النشر. التفاصيل في PR #25716.

تحميل الـ actions

الأسماء القصيرة مثل uses: actions/checkout@v4 تُحمَّل افتراضيًا من GitHub (https://github.com/actions/checkout.git). لاستخدام action من مستضيف آخر اكتب العنوان الكامل، مثل uses: https://gitea.com/actions/checkout@v4. المصدر الافتراضي إعداد على مستوى الخدمة يحدّده مدير الخدمة، لكن العنوان الكامل يعمل دائمًا أيًّا كان الإعداد.

إتاحة السياقات

لا يتحقّق ليڤانت غيت من إتاحة السياق في كل موضع كما يفعل GitHub، فتستطيع مثلًا استخدام السياق env في مواضع أكثر. هذا تساهل لا قيد، لكن لا تعتمد عليه إن كنت تريد أن يبقى الملف صالحًا على GitHub أيضًا.

مرجع الـ pull request

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

ماذا بعد؟

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