Libseccomp: RFE: الانتقال من travis-ci.org إلى travis-ci.com

لقد قمت بتسجيل الدخول إلى travis-ci.com ، لكنهم ما زالوا في المرحلة التجريبية ، وبالتالي لا يمكننا الانتقال بعد.

باه! إنهم بالتأكيد لا يجعلون ذلك سهلاً ، أليس كذلك؟ ؛)

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

لقد ذهبت للتو للتحقق من اكتمال بناء Travis بشكل جيد بعد بعض الدفعات واستقبلتني هذه الرسالة:

منذ 15 يونيو 2021 ، تم إيقاف البناء على موقع travis-ci.org. الرجاء استخدام travis-ci.com من الآن فصاعدًا.

... يبدو أننا بحاجة إلى معرفة ذلك ، قريبًا.

أنا متحفظ قليلاً من نموذج الأعمال الجديد لترافيس. يبدو أن المصدر المفتوح سيبقى مجانيًا (في الوقت الحالي) ، لكنهم لم يجعلوا الأمر سهلاً. قد نحتاج إلى طلب المزيد من "الائتمانات" بشكل دوري.
https://docs.travis-ci.com/user/billing-faq/#what -if-i-am-building-open-source

What if I am building open source? #

Each of the Travis CI Plans contains an amount of special OSS credits per month assigned to
run builds only on public repositories. To find out more about it please contact the Travis CI
support team. In the email please include:

* Your account name and your VCS provider (like travis-ci.com/github/[your account name] )
* How many credits (build minutes) you’d like to request (should your run out of credits again
  you can repeat the process to request more or to discuss a renewable amount)

آه ، هذا مقرف: /

أحتاج إلى تحديث ذاكرتي حول ما اكتشفته حول إجراءات GH ؛ كان بعيدًا عن الكمال ، ولكن بالنظر إلى تغييرات Travis CI ، فقد يكون الخيار الأفضل.

ها نحن ... # 299

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

يعد عدم وجود أقواس أخرى / ABI أمرًا مزعجًا ، ولكن من الناحية الواقعية لا نختبر كل قوس / ABI بشكل منتظم على أي حال (كيف يمكننا ذلك؟) لذا فهذه ليست نهاية العالم. إذا كان ذلك مفيدًا ، في حين أنه ليس "CI" لدي وظيفة ليلية تعمل على بعض البنية التحتية الخاصة التي تبني وتتحقق من فرع libseccomp الرئيسي في aarch64 ؛ إذا حدث شيء ما ، فسوف ألاحظ ذلك في غضون 24 ساعة تقريبًا. آمل أن نتمكن من اكتشاف شيء أفضل في المستقبل (لدي بعض الأفكار هنا ...).

drakenclimber الأفكار؟

أعتقد أن الخيار الأفضل الآن هو الانتقال إلى إجراءات GH والالتزام ببنيات x86_64 CI فقط في الوقت الحالي. يبدو أن هذا هو أسرع طريق لاستعادة اختبارات العلاقات العامة / الفروع وتغطية الكود بأقل قدر من الصداع.

يبدو أمرا جيدا لي. يمكنني أن أمتلك الانتقال لأنني قمت به بالفعل من أجل libcgroup.

لقد استخدمنا Github Actions في libcgroup منذ فترة طويلة ، وقد نجحنا كثيرًا. كان من السهل نقل الوظائف من ترافيس.

وقال إن عمليات جيثب نظام رصد السفن لا توفر ميزة نحتاجه في libcgroup (نظام V2 cgroup كامل)، لذلك أنا خلقت مؤخرا VM على الغيمة الحرة أوراكل و توصيله تصل عبر عداء الذاتي استضافت تطبيقات جيثب. كان من السهل الإعداد ، وعملت بشكل جيد حتى الآن. أعتقد أن منطق GH Actions المستضاف ذاتيًا يدعم aarch64 ، لذلك قد تكون هذه طريقة لاختبار ARM باستمرار إذا كان لدينا صندوق يمكننا توجيهه إليه.

يعد عدم وجود أقواس أخرى / ABI أمرًا مزعجًا ، ولكن من الناحية الواقعية لا نختبر كل قوس / ABI بشكل منتظم على أي حال (كيف يمكننا ذلك؟) لذا فهذه ليست نهاية العالم.

متفق. لقد أحببت مجموعة البنى التي تم اختبارها حاليًا حيث وجدت أحيانًا مشكلات غريبة 32 مقابل 64 بت وكبيرة مقابل صغيرة. قبل الإصدار ، يجب علينا (على الأقل) إجراء الاختبارات عبر البنى الأخرى. ربما يمكننا تجنيد المساهمين السابقين للمساعدة هنا.

(لدي بعض الأفكار هنا ...).

أنا كل آذان صاغية. أتمنى أن أتمكن من أخذ أفضل الأجزاء من GH Actions و Travis ووضعها في CI واحد.

(لدي بعض الأفكار هنا ...)

آسف ، كان يجب أن أكون أكثر وضوحًا. قصدت أنه قد يكون لدي بعض الأفكار حول دعم aarch64 ، وليس حول Travis / GH بشكل عام.

بغض النظر ، شكرًا لك على العمل على هذا في PR # 329.