Libseccomp: BUG: ابحث في استبدال Travis CI بإجراءات GitHub

فيما يلي دليل للانتقال من TravisCI إلى Github Actions. آمل أن أجرب هذا خلال الأيام القليلة المقبلة
https://docs.github.com/en/free-pro-team@latest/actions/learn -github-Actions / migrating-from-travis-ci-to-github-Actions

أنا حقًا أحب مظهر Github Actions. لقد أرسلت للتو مجموعة تصحيح لتبديل libcgroup من Travis CI إلى Github Actions.

https://github.com/drakenclimber/libcgroup/tree/issues/github_actions
https://sourceforge.net/p/libcg/mailman/message/37165461/

سأحاول تجميع مجموعة التصحيح لنقل libseccomp هذا الأسبوع.

هذا يبدو جيدًا @ drakenclimber ، شكرًا!

ها هي وضعي الحالي. لدي إجراءات Github تعمل على amd64 مع بعض الانحرافات الطفيفة عن حل Travis CI الحالي ، لكن لدي مخاوف بشأن البنى الأخرى.

الايجابيات:

• سهل الاستخدام. لقد تمكنت من إعداد سير عمل تكامل مستمر بسرعة في إجراءات Github
• من السهل أيضًا تغليف العمليات في إجراء . يمكن بعد ذلك إعادة استخدام هذه الإجراءات داخل سير العمل. (الغريب أن الإجراء لا يمكنه استدعاء إجراء آخر .)
• السرعة المقبولة (لـ amd64 على الأقل). اكتملت مجموعة الاختبار بأكملها في 22 دقيقة
• تم تحديد واجهة المستخدم الرسومية الجيدة والخطوات الفاشلة بوضوح
• تعجبني حقًا خيارات الموازاة في إجراءات Github ، وهي توفر ميزة لترتيب النتائج بمجرد اكتمال الوظائف الأخرى. أنا أستخدم هذه الميزة في libcgroup لإنهاء أرقام تغطية الكود بعد تشغيل جميع الاختبارات

سلبيات:

• لا يوجد دعم أصلي للبنى الأخرى
  
  
  
  • قدم موظف في github هذا الحل لتشغيل حاوية arm64 Docker. لقد جربته ، ومع بعض العبث ، تمكنت من الحصول على مجموعة الاختبار الأساسية التي تعمل في الغالب. (اختبار 52 - الحمل الأساسي - فشل لسبب غريب.) ولكن من الصعب إعادة إنتاج هذا الإعداد محليًا وتصحيح الأخطاء يمثل تحديًا كبيرًا. لم أتمكن من تشغيل اختبارات الثعبان. أوه ، إنه حقًا بطيء حقًا - استغرق الأمر ساعة لتشغيل مجموعة مختصرة من الاختبارات على arm64. استغرق ppc64el 6 ساعات قبل أن
  
  
  • أنشأ مستخدم github هذا الإجراء الذي يستخدم أيضًا حاويات Docker لتشغيل بنى غير أصلية. بناء الجملة صعب إلى حد ما وسيتطلب منا تكرار التعليمات البرمجية. على الرغم من ذلك ، فإن قائمة البنية والقائمة الأساسية المدعومة جيدة جدًا
  
  
  • يدعم Github Actions استخدام المتسابقين المستضافين ذاتيًا ، لذلك سيكون أحد الخيارات (القبيحة) هو العثور على مربع arm64 و ppc64le وما إلى ذلك واستخدامه لإجراء الاختبارات. ميزة هذا هو أن تصحيح الأخطاء سيكون أكثر وضوحًا من حاوية Docker
  
  

آخر:

• أنشأ Coveralls.io إجراء Github . يعمل حل TravisCI الحالي ، cpp-coveralls ، على إجراءات Github لكنه واجه صعوبات في الإنشاءات المتوازية. لدي عمل المعاطف الذي يعمل بالتوازي في libcgroup
• للاستفادة من إجراء المعاطف ، كان علي استدعاء lcov مباشرةً لإنشاء ملف lcov.info. ثم يتم تحميل هذا الملف إلى coveralls.io. لاحظ أن استخدام lcov ينتج مباشرةً أرقام تغطية مختلفة قليلاً. على سبيل المثال ، لا يحدد حل Travis CI ما إذا كان هذا الخط قد تم تغطيته أم لا أثناء استدعاء حل Github Actions صراحةً
• ملاحظة لنفسي - ليس لدي علامة --exclude src/arch-syscall-check.c lcov تعمل. لا يوجد دليل لماذا

ها هي وضعي الحالي. لدي إجراءات Github تعمل على amd64 مع بعض الانحرافات الطفيفة عن حل Travis CI الحالي ، لكن لدي مخاوف بشأن البنى الأخرى.

الايجابيات:

• سهل الاستخدام. لقد تمكنت من إعداد سير عمل تكامل مستمر بسرعة في إجراءات Github
• من السهل أيضًا تغليف العمليات في إجراء . يمكن بعد ذلك إعادة استخدام هذه الإجراءات داخل سير العمل. (الغريب أن الإجراء لا يمكنه استدعاء إجراء آخر .)
• السرعة المقبولة (لـ amd64 على الأقل). اكتملت مجموعة الاختبار بأكملها في 22 دقيقة
• تم تحديد واجهة المستخدم الرسومية الجيدة والخطوات الفاشلة بوضوح
• تعجبني حقًا خيارات الموازاة في إجراءات Github ، وهي توفر ميزة لترتيب النتائج بمجرد اكتمال الوظائف الأخرى. أنا أستخدم هذه الميزة في libcgroup لإنهاء أرقام تغطية الكود بعد تشغيل جميع الاختبارات

سلبيات:

• لا يوجد دعم أصلي للبنى الأخرى

  • قدم موظف في github هذا الحل لتشغيل حاوية arm64 Docker. لقد جربته ، ومع بعض العبث ، تمكنت من الحصول على مجموعة الاختبار الأساسية التي تعمل في الغالب. (اختبار 52 - الحمل الأساسي - فشل لسبب غريب.) ولكن من الصعب إعادة إنتاج هذا الإعداد محليًا وتصحيح الأخطاء يمثل تحديًا كبيرًا. لم أتمكن من تشغيل اختبارات الثعبان. أوه ، إنه حقًا بطيء حقًا - استغرق الأمر ساعة لتشغيل مجموعة مختصرة من الاختبارات على arm64. استغرق ppc64el 6 ساعات قبل أن
  • أنشأ مستخدم github هذا الإجراء الذي يستخدم أيضًا حاويات Docker لتشغيل بنى غير أصلية. بناء الجملة صعب إلى حد ما وسيتطلب منا تكرار التعليمات البرمجية. على الرغم من ذلك ، فإن قائمة البنية والقائمة الأساسية المدعومة جيدة جدًا
  • يدعم Github Actions استخدام المتسابقين المستضافين ذاتيًا ، لذلك سيكون أحد الخيارات (القبيحة) هو العثور على مربع arm64 و ppc64le وما إلى ذلك واستخدامه لإجراء الاختبارات. ميزة هذا هو أن تصحيح الأخطاء سيكون أكثر وضوحًا من حاوية Docker

آخر:

• أنشأ Coveralls.io إجراء Github . يعمل حل TravisCI الحالي ، cpp-coveralls ، على إجراءات Github لكنه واجه صعوبات في الإنشاءات المتوازية. لدي عمل المعاطف الذي يعمل بالتوازي في libcgroup
• للاستفادة من إجراء المعاطف ، كان علي استدعاء lcov مباشرةً لإنشاء ملف lcov.info. ثم يتم تحميل هذا الملف إلى coveralls.io. لاحظ أن استخدام lcov ينتج مباشرةً أرقام تغطية مختلفة قليلاً. على سبيل المثال ، لا يحدد حل Travis CI ما إذا كان هذا الخط قد تم تغطيته أم لا أثناء استدعاء حل Github Actions صراحةً
• ملاحظة لنفسي - ليس لدي علامة --exclude src/arch-syscall-check.c lcov تعمل. لا يوجد دليل لماذا

ماذا عن استخدام Vagrant على macOS؟

ماذا عن استخدام Vagrant على macOS؟

تتعلق هذه المشكلة بشكل خاص بنقل اختبار CI الخاص بنا من Travis CI إلى إجراءات GitHub وليس التطوير العام واختبار libseccomp. لست متأكدًا من أن MacOS هو خيار لـ GitHub Actions ، وحتى لو كان كذلك ، فمن المحتمل أن يكون خيارًا سيئًا بالنسبة لنا بسبب عدم وجود دعم kernel (اختباراتنا "الحية" محدودة ، ولكنها مهمة).

ها هي وضعي الحالي. لدي إجراءات Github تعمل على amd64 مع بعض الانحرافات الطفيفة عن حل Travis CI الحالي ، لكن لدي مخاوف بشأن البنى الأخرى.

شكرًا للنظر في drakenclimber ، الدعم الهندسي المحدود محبط للغاية. نظرًا لأننا لا نشهد بالفعل الكثير من المشكلات مع Travis CI في الوقت الحالي ، فربما نستمر مع Travis حتى يصبح مدمرًا؟

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

ماذا عن استخدام Vagrant على macOS؟

تتعلق هذه المشكلة بشكل خاص بنقل اختبار CI الخاص بنا من Travis CI إلى إجراءات GitHub وليس التطوير العام واختبار libseccomp. لست متأكدًا من أن MacOS هو خيار لـ GitHub Actions ، وحتى لو كان كذلك ، فمن المحتمل أن يكون خيارًا سيئًا بالنسبة لنا بسبب عدم وجود دعم kernel (اختباراتنا "الحية" محدودة ، ولكنها مهمة).

أنا على دراية كاملة بإجراءات GitHub. أنها تدعم macOS (راجع: https://github.com/actions/virtual-environment#available-environment). على وجه التحديد ، macOS هي البيئة الوحيدة التي تأتي مع Vagrant و VirtualBox (انظر: https://github.com/actions/virtual-enustain/issues/433).

من واقع خبرتي ، يتطلب الأمر مزيدًا من العمل للإعداد ، لكن التشغيل داخل جهاز افتراضي يضمن بيئة أكثر اتساقًا لخطوط أنابيب CI / CD. ناهيك عن أنه أكثر قابلية للنقل ، حيث يمكن لأي شخص تشغيل صور Vagrant / VirtualBox محليًا. كما أنه يجعل الانتقال إلى حل CI / CD جديد أسهل ، نظرًا لأن التكوين يكتب عادةً في نص برمجي ، مستقل عن إقرارات YAML الخاصة بالبائع.

هذا هو مجرد بلدي اثنين سنتا :)

شكرًا @ oxr463 ، من الجيد معرفة إجراءات GH. في هذه المرحلة ، أفضل عدم امتلاك إدارة إضافية لبيئة افتراضية ، ولكن هذا أمر يجب مراعاته إذا أصبح Travis CI مشكلة بالنسبة لنا.

نظرًا لأن نشاط Travis الخاص بنا خفيف نسبيًا ، فأنا آمل أننا لن نواجه مشاكل Travis التي شاهدتها بعض المشاريع الأخرى.

شكرًا للنظر في drakenclimber ، الدعم الهندسي المحدود محبط للغاية. نظرًا لأننا لا نشهد بالفعل الكثير من المشكلات مع Travis CI في الوقت الحالي ، فربما نستمر مع Travis حتى يصبح مدمرًا؟

نعم ، أعتقد أن هذه هي الإجابة الأفضل والأكثر أمانًا.

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

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

شكرا

من واقع خبرتي ، يتطلب الأمر مزيدًا من العمل للإعداد ، لكن التشغيل داخل جهاز افتراضي يضمن بيئة أكثر اتساقًا لخطوط أنابيب CI / CD. ناهيك عن أنه أكثر قابلية للنقل ، حيث يمكن لأي شخص تشغيل صور Vagrant / VirtualBox محليًا. كما أنه يجعل الانتقال إلى حل CI / CD جديد أسهل ، نظرًا لأن التكوين يكتب عادةً في نص برمجي ، مستقل عن إقرارات YAML الخاصة بالبائع.

شكرا ، oxr463. آمل أيضًا ألا نضطر إلى السير في هذا الطريق ، لكن من الجيد معرفة أن هناك خيارات أخرى متاحة.

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

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

يبدو أمرا جيدا لي. شكرا!

drakenclimber حدث لي شيء واحد - يجب أن نفكر في محاولة الهجرة من travis-ci.org إلى travis-ci.com حيث من المفترض أن تختفي ".org" "في غضون أسابيع".

أوه! لم أكن أعرف ذلك. شكرا!

سأحاول التقاط هذا الأسبوع المقبل بعد ذلك.