الصفحة الرئيسية>المتعلقة بالبرمجة>شفرة المصدر الأخرى
تنزيل

جارودا لينكس PKGBUILDs

يحتوي هذا المستودع على PKGBUILDs لجميع الحزم الموجودة حاليًا في مستودع garuda الخاص به. يتم تشغيله على GitLab بسبب الاستخدام المكثف لـ CI الخاص به ويحتوي على مرآة GitHub للقراءة فقط.

نطاق هذا الريبو

جميع PKGUILDs الخاصة بنا موجودة هنا. تاريخيًا، تم تقسيم هذه إلى مستودعاتها الخاصة. لتسهيل العثور على PKGBUILD الصحيح، وكذلك للسماح بالمساهمة بشكل أسرع، قمنا مؤخرًا بدمجها في هذا المستودع الجديد. تم تضمين جميع حزم PKGBUILDs بما في ذلك ملفات التكوين الخاصة بها (ينطبق هذا على الملفات الأصغر مثل garuda-fish-config ). بالنسبة لبعضها، مثل حزم garuda-*-settings ، قد يظل المحتوى موجودًا في المستودعات الخاصة بها.

هل وجدت أي مشكلة؟

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

كيف تساهم؟

نحن نقدر بشدة المساهمات من أي نوع! ؟ للقيام بذلك، يرجى اتباع الخطوات التالية:

  • قم بإنشاء شوكة لهذا المستودع.
  • استنساخ شوكتك محليًا (برنامج تعليمي قصير عن git).
  • أضف التغييرات المطلوبة إلى PKGBUILDs أو الكود المصدري.
  • تأكد من أن Shellcheck وshfmt يبلغان عن عدم وجود مشكلات في الملفات التي تم تغييرها
    • يجب تثبيت التبعيات المطلوبة من قبل، على سبيل المثال. عبر sudo pacman -S shfmt shellcheck
    • قم بتشغيل البرنامج النصي lint.sh عبر bash ./.ci/lint.sh وتحقق من الكود
    • قم بتطبيق اقتراحات معينة تلقائيًا عبر bash ./ci/lint.sh apply
  • التزم باستخدام رسالة التزام تقليدية وادفع أي تغييرات إلى مفترقك مرة أخرى.
    • يساعد تطبيق الالتزام في إنشاء رسالة التزام مناسبة. يمكنك تثبيته عبر النقطة لأنه لا توجد حاليًا حزمة في Arch repos: pip install --user -U Commitizen . ثم تابع عن طريق تشغيل cz commit في المجلد المستنسخ.
  • قم بإنشاء طلب دمج جديد في مستودعنا الرئيسي.
  • تحقق مما إذا كان أي من عمليات تشغيل الأنابيب قد فشل وقم بتطبيق الاقتراحات النهائية.

سنقوم بعد ذلك بمراجعة التغييرات ودمجها في النهاية.

التعامل مع بعض مشاكل التغليف

الحزم المهملة والمكسورة

هناك حالات لحزم مهملة، والتي لم تعد تخدم أي غرض وتتسبب أيضًا في عدم قدرة الأنظمة على التحديث. يمكن التعامل مع ذلك عن طريق إضافة الحزمة إلى conflicts() في garuda-common-settings وauto-pacman في garuda-update . والنتيجة هي إزالة الحزمة المخالفة تلقائيًا بسبب التعارض.

CI / أدوات البناء

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

عام

قد يتم تشغيل عمليات النشر تلقائيًا إما عن طريق تغيير المحتوى داخل دليل PKGBUILD أو إلحاق [deploy *] برسالة الالتزام. على عكس عمليات التحقق PKGBUILD، فهي متاحة فقط للالتزامات على الفرع main . المدعومة هي:

  • [deploy all] : ينشر روتين garuda الكامل، أي جميع PKGBUILDs الموجودة في هذا المستودع.
  • [deploy $pkgname] : لنشر الحزمة pkgname ، مما يعني أنه من خلال استبدالها garuda-bash-settings ، سيتم نشر garuda-bash-settings .

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

المطبات الآلية

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

  • لا ينطبق هذا على الحزم التي تحتوي على جميع ملفاتها في هذا المستودع
  • يجب ألا تكون العلامات مسبوقة بـ v
  • يتم توفير المعلومات المطلوبة حول مصدر الحزمة عبر ملف SOURCES. يتبع كل سطر المخطط $url $pkgname $project_id . يتم استخدام الأخير لاسترداد أحدث علامة عبر GitLab API ويمكن العثور عليه في صفحة الإعدادات العامة للمستودع.

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

تحديث الإصدارات يدويا

بالنسبة لبعض ملفات PKGBUILD، مثل garuda-fish-config ، توجد جميع الملفات في هذا المستودع. عند تحديث PKGBUILDs، يرجى التأكد أيضًا من تحديث ملف .SRCINFO المقابل حيث يتم استخدام هذا الملف لتحليل جميع المعلومات المتعلقة بالحزمة!

إضافة الحزم

تعد إضافة الحزم أمرًا سهلاً مثل إنشاء مجلد جديد يحمل اسم $pkgbase الخاص بالحزمة. ضع PKGBUILD وجميع الملفات الأخرى المطلوبة هنا. وبالتالي فإن إضافة حزم AUR أمر بسيط مثل استنساخ الريبو الخاص به وإزالة المجلد .git . تعتمد CI على ملفات .SRCINFO لتحليل معظم المعلومات، لذلك، من المهم أن تكون هذه الملفات جاهزة ومحدثة في حالة الحزم المُدارة ذاتيًا. أخيرًا، أضف مجلد .CI يحتوي على التكوين الأساسي (يلزم وجود CI_PKGBUILD_SOURCE في حالة عدم احتياج الحزمة الخارجية الخاصة به، أو PKBUILDs المُدارة ذاتيًا إلى ذلك)، وقم بإجراء أي تغييرات، ثم ادفع التغييرات مرة أخرى إلى الفرع الرئيسي. يرجى اتباع اتفاقية الالتزام التقليدية أثناء القيام بذلك (يمكن لـ cz-cli المساعدة في ذلك!). وهذا يعني ارتكاب مثل:

  • feat($pkgname): init
  • fix($pkgname): fix xyz
  • chore($pkgname): update PKGBUILD
  • ci(config): update

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

إزالة الحزم

يمكن القيام بذلك عن طريق إزالة المجلد الذي يحتوي على PKGBUILD الخاص بالحزمة. ستقوم مهمة التنظيف تلقائيًا بإزالة أي حزمة قديمة عبر تشغيل خط الأنابيب on-commit . سيأخذ هذا أيضًا في الاعتبار أي حزم مقسمة قد تنتجها الحزمة. تعتبر إعادة تسمية المجلدات بمثابة إزالة الحزم أيضًا.

خط أنابيب على الالتزام

عند دفع التزام جديد، سينفذ مسار CI الإجراءات التالية:

  • التحقق من وقت إنشاء آخر علامة scheduled . يُستخدم هذا لتحديد الحزم التي يجب جدولتها.
  • فهو يوزع كل التزام لسلسلة [deploy $foldername] ، ويقبل فقط القيم الصالحة المشتقة من مجلدات PKGBUILD الموجودة. [deploy all] هو معلمة صالحة أيضًا. الخطأ الإملائي $pkgname هو خطأ فادح هنا. يجب إصلاح أي مشكلات ودفعها بالقوة.
  • ثم يتم تحليل الملفات التي تم تغييرها. يتضمن هذا أيضًا الحزم التي تمت إزالتها. سيؤدي أي تغيير في محتوى المجلد ذي الصلة إلى نشر الحزمة المقابلة.
  • الإجراء الأخير هو إنشاء معلمات الجدول الزمني (تسليمها إلى المهمة المجدولة عبر العناصر) وإزالة جميع الحزم القديمة في حالة اكتشاف خطوة سابقة.
  • في حالة نجاح كل هذه الإجراءات، يتم تحديث العلامة scheduled ، حتى نتمكن من الرجوع إليها في عملية تشغيل لاحقة.

خط الأنابيب في الموعد المحدد

نصف ساعة

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

  • تحديث قالب CI من مستودع القوالب (في حالة تمكين ذلك عبر .ci/config )
  • تحقق مما إذا كانت العلامة المجدولة غير موجودة أو أن العلامة المجدولة لا تشير إلى HEAD (في هذه الحالة قم بإحباط المهمة!)
  • تحقق من وجود شجرة عمل .state التي تحتوي على حالة الحزم، وإذا كانت موجودة، فسيتم إعدادها. وإلا فإنه يعيد إنشائه من الصفر (على سبيل المثال، عند فرض الدفع)
  • تحقق مما إذا كان الالتزام الأخير تلقائيًا (يحتوي على "العمل الروتيني (الحزم): حزم التحديث [تخطي ci]")، إذا كانت الإجابة بنعم، فسيقوم الالتزام الناتج عن الجدول بالكتابة فوقه للحفاظ على سجل الالتزام نظيفًا.
  • قم بتجميع الطوابع الزمنية لـ AUR للحزم لتحديد ما إذا كان PKGBUILD قد تغير أم لا
  • قم بالمراجعة عبر كل حزمة صالحة وقم بتنفيذ الإجراءات التالية:
    • اقرأ ملف .CI/config للحصول على معلومات حول تكوين الحزمة (على سبيل المثال، ما إذا كنت تريد إدارة مستودع AUR، أو مصدر PKGBUILD، وما إلى ذلك)
    • قم بتحديث PKGBUILD في الحالات التالية:
      • تم تعيين CI_PKGBUILD_SOURCE على gitlab : يقوم بتحديث PKGBUILD من علامات مستودع GitLab
      • تم تعيين CI_PKGBUILD_SOURCE على aur : يقوم بتحديث PKGBUILD من مستودع AUR، وسحب git repo واستبدال الملفات الموجودة بالملفات الجديدة. إذا تعذر جمع الطابع الزمني AUR مسبقًا، فسيتم تخطي تحديث الحزمة.
      • لم يتم تعيين CI_PKGBUILD_SOURCE على gitlab أو aur : يحاول تحديث PKGBUILD عن طريق سحب المستودع المحدد في CI_PKGBUILD_SOURCE. في حالة عدم نجاح الاستنساخ بعد محاولتين، يتم تخطي عملية التحديث.
    • في حالة تعيين CI_GIT_COMMIT في متغيرات تكوين الحزم، يتم تحديث الالتزام الأخير لعنوان URL لـ git المعين في قسم source في PKGBUILD. إذا كان يختلف، جدولة البناء.
    • في حالة وجود ربط مخصص ( .CI/update.sh داخل دليل الحزمة)، يتم تنفيذه - يمكن استخدام هذا لتحديث PKGBUILDs باستخدام برنامج نصي مخصص.
    • كتابة المتغيرات المطلوبة مرة أخرى إلى .CI/config (على سبيل المثال، Git hash)
  • إما أن تقوم بتحديث PKGBUILD بصمت في حالة حدوث تغييرات طفيفة، أو إنشاء PR للمراجعة في حالة التحديثات الرئيسية (وفقط إذا كان CI_HUMAN_REVIEW صحيحًا)
    • يتم أخذ التحديثات في الاعتبار فقط إذا كانت الاختلافات تشير بالفعل إلى تغييرات بين مجلد PKGBUILD الحالي ومستودع AUR PKGBUILD
    • تم الكشف عن أي تغيير تم إجراؤه على الملفات المصدر، إلا أن هذا لا يكشف عن التغييرات الضارة في مصدر المشروع الأولي الذي تنشئه الحزمة
  • يتم تحديث شجرة عمل الحالة بمعلومات جديدة
  • يتم إنشاء معلمات الجدول الزمني وتسليمها إلى المهمة المجدولة عبر قطعة أثرية
  • يتم تقليم الفروع القديمة (على سبيل المثال، ممثلو المستفيدين الرئيسيين للمراجعة المدمجة).
  • يتم تحديث العلامة المجدولة مرة أخرى

يوميًا

تمت إضافة جدول تدفق يومي لحزم محددة تعمل على إنشاء pkgver الخاص بها ديناميكيًا. للاستفادة منه، قم بتعيين CI_ON_TRIGGER=daily داخل ملف .CI/config الخاص بالحزمة.

الجدولة اليدوية

جدولة الحزم دون التزامات git

يمكن إضافة الحزم إلى الجدول يدويًا عن طريق الانتقال إلى صفحة تشغيل خط الأنابيب، وتحديد "تشغيل خط الأنابيب" وإضافة PACKAGES كمتغير مع أسماء الحزم كقيمة لها. سيقوم خط الأنابيب بعد ذلك بالتقاط الحزم وجدولتها. يمكن أيضًا تعيين PACKAGES على all لجدولة جميع الحزم. في حالة جدولة حزمة واحدة أو أكثر، فإنها تحتاج إلى اتباع التنسيق pkgname1:pkgname2:pkgname3 .

تشغيل خطوط الأنابيب المجدولة حسب الطلب

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

إضافة التدخل

ضع ملف التداخل المطلوب في المجلد .CI الخاص بمجلد PKGBUILD:

  • prepare : برنامج نصي يتم تنفيذه بعد إعداد جذر المبنى. يمكن استخدامه لمصدر متغيرات البيئة أو تعديل أشياء أخرى قبل بدء التجميع.
    • إذا كان هناك حاجة إلى إعداد شيء ما قبل عملية الترجمة الفعلية، فيمكن دفع الأوامر عن طريق الإدراج على سبيل المثال. $CAUR_PUSH 'source /etc/profile' . وبالمثل، يمكن حل تعارضات الحزم، على سبيل المثال. كما يلي: $CAUR_PUSH 'yes | pacman -S nftables' (علامات الاقتباس المفردة مهمة لأننا نريد أن يتم تقييم المتغيرات/الأنابيب في وقت تشغيل الضيف وليس أثناء التدخل)
  • interfere.patch : ملف تصحيح يمكن استخدامه لإصلاح ملفات متعددة أو PKGBUILD إذا كانت هناك حاجة إلى الكثير من التغييرات. يجب إضافة كافة التغييرات إلى هذا الملف.
  • PKGBUILD.prepend : تتم إضافة محتويات هذا الملف إلى بداية PKGBUILD.
  • PKGBUILD.append : تتم إضافة محتويات هذا الملف إلى نهاية PKGBUILD. يعد إصلاح build() أمرًا سهلاً مثل إضافة build() الثابتة إلى هذا الملف. يمكن استخدام هذا لجميع أنواع الإصلاحات. إذا كان هناك شيء يحتاج إلى إضافته إلى مصفوفة، فهذا أمر سهل مثل makedepend+=(somepackage) .
  • on-failure.sh : البرنامج النصي الذي يتم تنفيذه في حالة فشل الإنشاء.
  • on-success.sh : البرنامج النصي الذي يتم تنفيذه في حالة نجاح البناء.

اصطدام pkgrel

يتم تنفيذ ذلك الآن عن طريق إضافة المتغير المطلوب CI_PACKAGE_BUMP إلى .CI/config . انظر أدناه لمزيد من المعلومات.

أشجار التبعية

يقوم CI ببناء أشجار التبعية تلقائيًا. يتم تمريرها إلى مدير Chaotic باعتبارها قطعة أثرية CI ويتم قراءتها عند تنفيذ أمر الجدول. ليست هناك حاجة للتدخل اليدوي.

.CI/التكوين

يحتوي ملف .CI/config داخل كل دليل حزمة على علامات إضافية للتحكم في خطوط الأنابيب وبناء العمليات باستخدامها.

  • CI_MANAGE_AUR : من خلال تعيين هذا المتغير على true ، سيقوم CI بتحديث مستودع AUR المقابل في نهاية تشغيل المسار في حالة حدوث تغييرات (مع حذف الملفات المتعلقة بـ CI)
  • CI_PACKAGE_BUMP : يتحكم في نتوءات الحزمة لجميع الحزم التي لم يتم ضبط CI_MANAGE_AUR عليها على true . يزيد pkgrel بمقدار 0.1 لكل زيادة +1 لهذا المتغير.
  • CI_PKGBUILD_SOURCE : يضبط المصدر لجميع الملفات المرتبطة بـ PKGBUILD، المستخدمة لسحب الملفات المحدثة من المستودعات البعيدة. القيم الصالحة حتى الآن هي:
    • gitlab : يسحب PKGBUILD من علامات مستودع GitLab. يجب أن يتبع التنسيق gitlab:$PROJECT_ID . يمكن الحصول على المعرف من خلال تصفح القسم العام لإعدادات المستودع.
    • aur : يسحب PKGBUILD من مستودع AUR، ويسحب git repo ويستبدل الملفات الموجودة بملفات جديدة.
  • CI_ON_TRIGGER : يمكن توفيره في حالة ضرورة قيام مشغل جدول زمني خاص بجدولة الحزمة المقابلة. يمكن استخدام هذا لجدولة الحزم يوميًا، عن طريق ضبط القيمة على daily . نظرًا لأن هذا يتحقق مما إذا كان "$TRIGGER == $CI_ON_TRIGGER"، يمكن إنشاء أي جدول مخصص باستخدام جداول التدفق وتعيين TRIGGER على midnight ، وإضافة جدول مناسب وتعيين CI_ON_TRIGGER لأي حزمة متأثرة حتى midnight .
  • CI_REBUILD_TRIGGERS : قم بإضافة الحزم المعروفة بأنها تسبب إعادة بناء لهذا المتغير. يتم توفير قائمة بالمستودعات لتتبع إصدارات الحزمة من خلال معلمة CI_LIB_DB الخاصة بالمستودعات. يتم تجزئة كل إصدار من الحزمة وإلقائه في .ci/lib.state . يقوم كل تشغيل مجدول بمقارنة الإصدارات عن طريق التحقق من عدم تطابق التجزئة وسيقوم بإرجاع كل حزمة متأثرة عبر CI_PACKAGE_BUMP .
  • BUILDER_CACHE_SOURCES : يمكن ضبطه على true في حالة ضرورة تخزين المصادر مؤقتًا بين الإصدارات. يمكن أن يكون هذا مفيدًا في حالة المصادر البطيئة أو المصادر غير المتوفرة طوال الوقت. سيتم مسح المصادر تلقائيًا بعد شهر واحد، وهو أمر مهم في حالة إزالة الحزم أو تغيير المصدر.

إدارة حزم AUR

يمكن أيضًا إدارة حزم AUR عبر هذا المستودع بطريقة آلية باستخدام .CI_CONFIG . وهذا يعني أنه بعد كل مسار مجدول ومقيد، سيتم تحديث مستودع AUR ليعكس التغييرات التي تم إجراؤها على ملفات مجلد PKGBUILD. سيتم حذف الملفات غير ذات الصلة بصيانة AUR (مثل مجلدات .CI ). تعكس رسالة الالتزام حقيقة أن الالتزام تم إنشاؤه بواسطة خط أنابيب CI ويحتوي على رابط لسجل الالتزام الخاص بالمستودع المصدر وتشغيل المسار الذي أدى إلى تنفيذ التزام التحديث.

تحديث البرامج النصية لـ CI

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

مشاكل وفشل خطوط الأنابيب

فشل آخر خط أنابيب قيد الالتزام

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

إعادة تعيين قائمة انتظار البناء

قد تكون هناك حالات نادرة تتطلب إعادة تعيين قائمة انتظار البناء. يمكن القيام بذلك عن طريق إيقاف تشغيل نسخة Redis المركزية، وإزالة ملف التفريغ الخاص بها، وإعادة تشغيل الخدمة.

مدير الفوضى

يتم توزيع هذه الأداة كحاويات Docker وتتكون من زوج من مثيلات المدير والمنشئ.

  • المدير: registry.gitlab.com/garuda-linux/tools/chaotic-manager/manager
  • المنشئ: registry.gitlab.com/garuda-linux/tools/chaotic-manager/builder
    • يحتوي هذا على المنطق الفعلي وراء إنشاءات الحزم (الموضحة هنا) المعروفة من الأشعة تحت الحمراء 3.0 مثل interfere.sh و database.sh وما إلى ذلك.
    • يختار الحزم التي سيتم إنشاؤها من مثيل Redis المُدار بواسطة مثيل المدير

يتم استخدام المدير بواسطة GitLab CI في مهمة schedule-package ، وجدولة الحزم عن طريق إضافتها إلى قائمة انتظار البناء. يمكن استخدام المُنشئ بواسطة أي جهاز قادر على تشغيل الحاوية. سيتم اختيار الوظائف المتاحة من مثيل Redis المركزي الخاص بنا.

إعداد التطوير

يحتوي هذا المستودع على شريحة NixOS، والتي يمكن استخدامها لإعداد الأشياء المطلوبة مثل الخطافات وعمليات التحقق المسبقة، بالإضافة إلى الأدوات المساعدة المطلوبة، تلقائيًا عبر direnv. يتضمن ذلك التحقق من PKGBUILDs عبر shellcheck و shfmt . هناك حاجة إلى nix (مدير الحزم) وdirenv، بعد ذلك، يمكن الدخول إلى البيئة عن طريق تشغيل direnv allow .

يوسع
معلومات إضافية
تطبيقات ذات صلة
نوصي لك
أخبار ذات صلة الكل