इन समस्याओं के अपने सारांश के लिए धन्यवाद!

क्या यह संभव है कि नौकरियों को केवल उन जगहों पर अक्षम किया जाए जहां वे विफल हो रहे हैं?

crypto और fcrypt प्लगइन @mpranj ने बताया कि उच्च सर्वर लोड की स्थिति में gpg-agent विफल हो सकते हैं। शायद हम crypto और fcrypt प्लगइन परीक्षण के लिए एक अलग बिल्ड जॉब बना सकते हैं? ताकि अन्य विकास अवरुद्ध न हो।

आपके इनपुट के लिए धन्यवाद!

समस्याग्रस्त नौकरियों को अलग करने से पुनर्निर्माण चक्र कम हो सकते हैं। लेकिन मुझे लगता है कि यह स्पष्ट है कि हम किसी भी तरह के मैनुअल पुनर्निर्माण नहीं चाहते हैं। तो हमारे पास विकल्प हैं:

• इसे और अधिक विश्वसनीय बनाना
• कुछ स्वचालित लूप जो इस तरह की त्रुटियों पर पुन: प्रयास करते हैं
• परीक्षणों को अक्षम करना (जब कोई इन भागों पर काम करता है, तो उसे फिर से सक्रिय करने की आवश्यकता होती है)

तुम क्या सोचते हो?

• इसे और अधिक विश्वसनीय बनाना

जब तक हम gpg-agent (जो कि बैच की नौकरियों में दर्द है) का उपयोग करना मुश्किल है

• कुछ स्वचालित लूप जो इस तरह की त्रुटियों पर पुन: प्रयास करते हैं

यह मुझे गंदा लगता है।

• परीक्षणों को अक्षम करना (जब कोई इन भागों पर काम करता है, तो उसे फिर से सक्रिय करने की आवश्यकता होती है)

ऐसा विकल्प लगता है जो कम से कम असुविधा का कारण बनता है, हालांकि मैनुअल रिग्रेशन परीक्षण होना भी अच्छा नहीं है।

जैसा कि बैठक में चर्चा की गई: हमें परीक्षणों को अक्षम करना चाहिए।

बैठक में वैकल्पिक पर भी चर्चा की गई: ctest --rerun-failed का उपयोग करना

ctest फ़ाइल <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log ctest बनाता है (टाइमस्टैम्प केवल डैशबोर्ड मोड में उपयोग किया जाता है)। इस फ़ाइल का उपयोग ctest --rerun-failed (किटवेयर / सीएमके @ eb2decc02d28f41a3e189d5387be24552c42060f) द्वारा भी किया जाता है। इसमें बस परीक्षणों की संख्या और नाम शामिल हैं जो पिछले असफल रहे।

मेरा प्रस्ताव पहले की तरह ctest कॉल करना होगा। यदि असफलता से बाहर निकलता है, तो जाँच करने के लिए grep LastTestsFailed.log का उपयोग करें यदि जाँच की गई कि ऊपर सूचीबद्ध कोई एक परीक्षण विफल हो गया है। और उसके बाद ही ctest --rerun-failed । यह आउटपुट को कम डुप्लिकेट / भ्रमित करता है।

लेकिन अगर समस्या वास्तव में उच्च सर्वर लोड है जो बहुत मदद नहीं करेगा। इसके बजाय हम ctest --test-load कोशिश कर सकते हैं। यह ctest का कारण CPU लोड को एक निश्चित सीमा से कम रखना चाहिए।

IMO फिर भी सबसे अच्छा विकल्प होगा कि आप परीक्षणों को निष्क्रिय कर सकें और एक छोटा सा निर्माण कार्य बना सकें जो केवल इन प्लगइन्स / पुस्तकालयों द्वारा आवश्यक निर्भरता को स्थापित करता है, केवल यह संकलित करता है कि क्या आवश्यक है और केवल समस्याग्रस्त परीक्षण चलाते हैं। इस तरह हम शायद कुछ ही मिनटों में रनटाइम प्राप्त कर सकते हैं, इस मामले में मैनुअल रीस्टार्टिंग स्वीकार्य होगा जो मुझे लगता है। हमारे FreeBSD नौकरियों की तुलना के लिए वर्तमान में ~ 200 परीक्षण चलाने के लिए लगभग 10 मिनट (7 मिनट का निर्माण, 2 मिनट का परीक्षण, 1 मिनट अन्य) लगते हैं।

पुनश्च। हमारे सेटअप के बारे में निश्चित नहीं है, लेकिन एक निश्चित चरण से जेनकींस पाइपलाइन को फिर से शुरू करना संभव है

मीटिंग में वैकल्पिक पर भी चर्चा की गई: ctest --rerun का प्रयोग विफल रहा

इसे देखने के लिए धन्यवाद!

लेकिन अगर समस्या वास्तव में उच्च सर्वर लोड है जो बहुत मदद नहीं करेगा। इसके बजाय हम ctest --test-load की कोशिश कर सकते हैं।

@ingwinlu ने इस दिशा में बहुत काम किया। हमारे सर्वर में उच्च भार के साथ उच्चतम प्रवाह है। यानी हम ऐसे विकल्पों के साथ अपने परीक्षणों को धीमा कर देंगे।

IMO अभी भी सबसे अच्छा विकल्प परीक्षणों को निष्क्रिय करना और एक छोटी बिल्ड जॉब बनाना होगा जो केवल स्थापित करता है

मॉड्यूलर परीक्षण के मामलों को प्राप्त करना और बनाए रखना बहुत मुश्किल है। @ingwinlu ने इसमें बहुत काम किया। मुझे लगता है कि हम केवल कुछ अविश्वसनीय परीक्षणों के लिए इस प्रयास को फिर से नहीं रख सकते।

पुनश्च। हमारे सेटअप के बारे में निश्चित नहीं है, लेकिन एक निश्चित चरण से जेनकींस पाइपलाइन को फिर से शुरू करना संभव है

वह महान होगा। लेकिन मुझे हमारे GUI में रिस्टार्ट बटन दिखाई नहीं देता है। क्या हमें एक और प्लगइन या एक नए संस्करण की आवश्यकता है? @ingwinlu ने सभी पाइपलाइन चरणों के लिए "

ऐसा लगता है कि हमारे पास अभी भी विफलताएं हैं (dbus देखें # 2532)

मैक के लिए dbus परीक्षण मामलों को छोड़कर क्या होता है?

ऐसा लगता है कि हमारे पास अभी भी विफलताएं हैं (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.

क्या आप इसे स्थानीय स्तर पर पुन: पेश करने में सक्षम थे?

हम अभी भी नहीं जानते कि यह समस्या छिटपुट रूप से क्यों होती है। यदि आपके पास कोई इनपुट है, तो यह बहुत अच्छा होगा।

हो सकता है कि हम समस्याग्रस्त बिल्ड नौकरियों से परीक्षणों को केवल बाहर कर सकते हैं? या हर निर्माण कार्य पर डब * टेस्टस विफल हो जाते हैं जहां यह चलता है?

क्या आप इसे स्थानीय स्तर पर पुन: पेश करने में सक्षम थे?

दुर्भाग्य से नहीं। मैं उबंटू पर हूं।

हो सकता है कि हम समस्याग्रस्त बिल्ड नौकरियों से परीक्षणों को केवल बाहर कर सकते हैं? या हर निर्माण कार्य पर डब * टेस्टस विफल हो जाते हैं जहां यह चलता है?

मैंने सिर्फ यह देखते हुए कि यह फिर से होता है, निर्माण कार्य को फिर से शुरू किया।

कृपया neccessary अगर मुझे फिर से असाइन करें।

मैंने अब # 3224 में ctest की स्वचालित रीट्री लागू की। यदि आप अभी भी परीक्षण सूट की अस्थायी विफलताओं का अनुभव करते

जेनकिंस / डॉकटर की अन्य विफलताओं के लिए, हमें अन्य समाधान खोजने की आवश्यकता है लेकिन पहले हमें अंत में प्रवास करने की आवश्यकता है। तो कृपया इन मामलों में नौकरी को फिर से शुरू करें।