شكرا لك على تلخيصك لهذه المشاكل!

هل من الممكن تعطيل الوظائف فقط في الأماكن التي يفشلون فيها؟

بالنسبة للمكوِّن الإضافي crypto و fcrypt mpranj ، أشار gpg-agent قد يفشل في حالة زيادة تحميل الخادم. ربما يمكننا إنشاء وظيفة إنشاء منفصلة لاختبارات المكون الإضافي crypto و fcrypt ؟ حتى لا يتم حظر التطورات الأخرى.

شكرا لك على المدخلات الخاصة بك!

قد يؤدي فصل الوظائف الإشكالية إلى جعل دورات إعادة البناء أقصر. لكني أعتقد أنه من الواضح أننا لا نريد أي إعادة بناء يدوية على الإطلاق. لذلك لدينا الخيارات:

• مما يجعلها أكثر موثوقية
• بعض الحلقات التلقائية التي تعيد المحاولة على مثل هذه الأخطاء
• تعطيل الاختبارات (عندما يعمل شخص ما على هذه الأجزاء ، عليها تفعيلها مرة أخرى)

ما رأيك؟

• مما يجعلها أكثر موثوقية

بالكاد ممكن طالما أننا نستخدم gpg-agent (وهو ألم في الوظائف المجمعة)

• بعض الحلقات التلقائية التي تعيد المحاولة على مثل هذه الأخطاء

هذا شعور قذر بالنسبة لي.

• تعطيل الاختبارات (عندما يعمل شخص ما على هذه الأجزاء ، عليها تفعيلها مرة أخرى)

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

كما نوقش في الاجتماع: يجب تعطيل الاختبارات.

تمت مناقشة البديل أيضًا في الاجتماع: استخدام ctest --rerun-failed

يؤدي تشغيل ctest إنشاء الملف <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log (يتم استخدام الطابع الزمني فقط في وضع لوحة المعلومات). يتم استخدام هذا الملف أيضًا بواسطة ctest --rerun-failed (راجع Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f). إنه يحتوي ببساطة على أرقام وأسماء الاختبارات التي فشلت في آخر مرة.

اقتراحي هو استدعاء ctest كما كان من قبل. إذا لم تنجح عملية الخروج ، فاستخدم grep على LastTestsFailed.log للتحقق من فشل أحد الاختبارات المذكورة أعلاه. وعندها فقط استخدم ctest --rerun-failed . يؤدي هذا إلى إخراج أقل مكررة / مربكة.

ولكن إذا كانت المشكلة حقًا هي تحميل خادم مرتفع فلن يساعد ذلك كثيرًا. بدلاً من ذلك يمكننا تجربة ctest --test-load . يجب أن يتسبب هذا في إبقاء ctest حمل وحدة المعالجة المركزية أقل من عتبة معينة.

لا يزال الخيار الأفضل IMO هو تعطيل الاختبارات وإنشاء مهمة بناء صغيرة تقوم فقط بتثبيت التبعيات التي تحتاجها هذه المكونات الإضافية / المكتبات ، وتجمع فقط ما هو ضروري وتقوم فقط بتشغيل الاختبارات الإشكالية. بهذه الطريقة يمكننا الحصول على وقت التشغيل على الأرجح لبضع دقائق ، وفي هذه الحالة سيكون إعادة التشغيل اليدوي مقبولًا على ما أعتقد. للمقارنة ، تستغرق وظائف FreeBSD حاليًا حوالي 10 دقائق (7 min build، 2 min test، 1 min other) لتشغيل ~ 200 اختبار.

ملاحظة. لست متأكدًا من إعدادنا ، ولكن إعادة تشغيل خط أنابيب جينكينز من مرحلة معينة يجب أن يكون ممكنًا

نوقش البديل أيضًا في الاجتماع: استخدام ctest --rerun-failed

شكرا لكم للنظر في ذلك!

ولكن إذا كانت المشكلة حقًا هي تحميل خادم مرتفع فلن يساعد ذلك كثيرًا. بدلاً من ذلك يمكننا تجربة ctest --test-load.

ingwinlu قام بالكثير من العمل في هذا الاتجاه. تتمتع خوادمنا بأعلى معدل نقل مع حمولة عالية. أي أننا سوف نبطئ اختباراتنا بمثل هذه الخيارات.

لا يزال الخيار الأفضل IMO هو تعطيل الاختبارات وإنشاء مهمة بناء صغيرة تقوم فقط بتثبيت

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

ملاحظة. لست متأكدًا من إعدادنا ، ولكن إعادة تشغيل خط أنابيب جينكينز من مرحلة معينة يجب أن يكون ممكنًا

هذا سيكون رائع. لكني لا أرى زر إعادة التشغيل في واجهة المستخدم الرسومية الخاصة بنا. هل نحتاج إلى مكون إضافي آخر أو إصدار أحدث؟ ingwinlu حاول إضافة "jenkins build * please" لجميع خطوات خطوط الأنابيب ، لسوء الحظ ، لم ينجح.

يبدو أنه لا يزال لدينا فشل (dbus ، انظر رقم 2532)

ماذا عن استبعاد حالات اختبار dbus لأجهزة Mac؟

يبدو أنه لا يزال لدينا فشل (dbus ، انظر رقم 2532)

نعم فعلنا.

gcc --version

Configured with: --prefix=/Applications/Xcode-10.2.1.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode-10.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1

Apple LLVM version 10.0.1 (clang-1001.0.46.4)

Target: x86_64-apple-darwin18.5.0

Thread model: posix

InstalledDir: /Applications/Xcode-10.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

(...)

DBUSRECV TESTS

==============

testing prerequisites

detecting available bus types - please ignore single error messages prefixed with "connect:"

connect: Failed to open connection to system message bus: Failed to connect to socket /usr/local/var/run/dbus/system_bus_socket: No such file or directory

test commit

test adding keys

../src/plugins/dbusrecv/testmod_dbusrecv.c:228: error in test_keyAdded: string "system/tests/testmod_dbusrecv/added" is not equal to "user/tests/foo/bar"

    compared: expectedKeyName and keyName (test_callbackKey)

test adding keys

testmod_dbusrecv Results: 34 Tests done — 1 error.

هل كنت قادرًا على إعادة إنتاجه محليًا؟

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

ربما يمكننا ببساطة استبعاد الاختبارات من وظائف البناء الإشكالية؟ أو هل تفشل اختبارات dbus * في كل وظيفة بناء يتم تشغيلها فيها؟

هل كنت قادرًا على إعادة إنتاجه محليًا؟

للأسف لا. أنا على أوبونتو.

ربما يمكننا ببساطة استبعاد الاختبارات من وظائف البناء الإشكالية؟ أو هل تفشل اختبارات dbus * في كل وظيفة بناء يتم تشغيلها فيها؟

لقد قمت للتو بإعادة تشغيل وظيفة البناء لمعرفة ما إذا كانت ستحدث مرة أخرى

يرجى إعادة تعيين لي إذا لزم الأمر.

لقد قمت الآن بتنفيذ إعادة المحاولة التلقائية لـ ctest في # 3224. إذا كنت لا تزال تواجه حالات فشل مؤقتة في مجموعات الاختبار ، فيرجى إعادة فتح المشكلة. (يمكننا زيادة عدد المحاولات).

بالنسبة لإخفاقات Jenkins / Docker الأخرى ، نحتاج إلى إيجاد حلول أخرى ولكن أولاً نحتاج في النهاية إلى الترحيل. لذا يرجى الاستمرار في إعادة تشغيل الوظيفة في هذه الحالات.