Libelektra: सर्वर सामग्री बनाएँ

@ मार्कस2330

बस कुछ बिल्ड सिस्टम से संबंधित सुधारों को आगे बढ़ाया। लेकिन आपको अपनी स्थिर डेबियन-स्थिर मशीन पर भी कुछ पैकेजों को ठीक करने की आवश्यकता है:

• कृपया wheezy-backports से qtdeclarative5-dev इंस्टॉल करें (आप बाद में /opt/Qt5.3.0 को हटा सकते हैं)
• कृपया java8 को पैकेज के रूप में स्थापित करें:
  
  
  
  • इस विधि का प्रयोग करें: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  
  
  • सेमेक को वास्तव में jdk8 खोजने दें: cd /usr/lib/jvm/ && ln -s java-8-oracle default-java
  
  
  • echo -e "/usr/lib/jvm/java-8-oracle/jre/lib/amd64\n/usr/lib/jvm/java-8-oracle/jre/lib/amd64/server" > /etc/ld.so.conf.d/java-8-oracle.conf && ldconfig
  
  
  • किल + स्थानीय जेनकींस जावा प्रक्रिया को पुनरारंभ करें। अन्यथा सभी निर्माण विफल हो जाएंगे
  
  
  • वैकल्पिक: jdk7 निकालें
  
  

अच्छा लग रहा है, उन मुद्दों को ठीक करने के लिए धन्यवाद।

मैंने उन चरणों को डेबियन-स्थिर एजेंट पर भी किया।

अन्य मशीनों के लिए qtdeclarative5-dev स्थापित करना संभव नहीं था, क्योंकि यह qdbus के साथ विरोध करता है जिसकी kde4 को आवश्यकता होती है। इसलिए मैंने पिछली स्क्रिप्ट कॉन्फ़िगर-डेबियन-व्हीज़ी को कॉन्फ़िगर-डेबियन-व्हीज़ी-लोकल के रूप में पुनर्स्थापित किया।

मैंने README.md में नोट्स के रूप में आपके द्वारा बताए गए इंस्टॉलेशन स्टेप्स को भी जोड़ा क्योंकि वे दूसरों के लिए रुचिकर हो सकते हैं।

एजेंटों को अपग्रेड करने के लिए धन्यवाद!

सामान जो स्थिर पर गायब है

1.) लेटेक्स (+ मुझे लगता है कि टेक्सलाइव-लेटेक्स-अनुशंसित भी आवश्यक है)
देखें http://build.libelektra.org :8080/job/elektra-doc/495/console

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.8") 
CMake Warning at doc/CMakeLists.txt:46 (message):
  Latex not found, PDF Manual can't be created.


-- Found Perl: /usr/bin/perl (found version "5.20.2") 
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_EXAMPLES

2.) क्या आप क्लैंग इंस्टॉल कर सकते हैं (इलेक्ट्रा-क्लैंग के लिए, क्लैंग ऑफ व्हीजी काम नहीं करेगा)?
3.) क्या आप इलेक्ट्रा-जीसीसी-कॉन्फ़िगर-मिंगव के लिए मिंगव + वाइन स्थापित कर सकते हैं?

apt install --no-install-recommends doxygen-latex + बजना + मिंगव किया

आपको शराब की आवश्यकता क्यों है?

बीटीडब्ल्यू, आपको i586-mingw32msvc-X से i686-w64-mingw32-X में Toolchain-mingw32.cmake बदलना चाहिए। अभी यह अस्थिर पर काम नहीं करेगा।

डॉक्यू के लिए धन्यवाद!

क्रॉस-संकलित विंडोज़ बायनेरिज़ को निष्पादित करने के लिए वाइन की आवश्यकता होती है (उदाहरण के लिए Exporterrors.exe)

मुझे लगता है कि आपने मिंगव स्थापित किया है जो w64 के लिए बनाता है। Mingw32 पैकेज में, अभी भी एक /usr/bin/i586-mingw32msvc-c++ ।

W64 के लिए एक नई टूलचेन फ़ाइल की फिर भी सराहना की जाती है।

मैंने gcc-mingw-w64-i686 स्थापित किया जो लक्ष्य के रूप में i686 के साथ mingw का x64 बिल्ड है।
पैकेज mingw32-binutils को हटा दिया गया है और अब अस्थिर पर उपलब्ध नहीं है।

दोनों कंटेनरों पर शराब स्थापित।

दरअसल, मिंगव बिल्ड स्थिर होने के लिए बाध्य है, इसलिए यह कोई मुद्दा नहीं होना चाहिए।

MinGW-w64 मिंगव पर एक कांटा है और काफी अलग लक्ष्य है। अभी तक किसी ने इसका परीक्षण नहीं किया।

शराब स्थापित करने के लिए धन्यवाद

Mingw-w64 बेहतर दिखता है। शायद यह आगे बढ़ने का समय है :-)

योगदान का स्वागत है;) मेरे पास इसका परीक्षण करने के लिए कोई मशीन नहीं है।

मुझे डर है कि आपको गलत शराब मिल गई है, यह उपयुक्त होना चाहिए-शराब स्थापित करें32

यह भी देखें http://build.libelektra.org :8080/job/elektra-gcc-configure-mingw/218/console

नहीं।

root@debian-stable:~# apt-get install wine32
....
E: Package 'wine32' has no installation candidate

ठीक है, dpkg --add-architecture i386 इसे हल करेगा। लेकिन क्या आप मिंगव/वाइन जॉब को अपनी बिल्ड मशीन पर पिन नहीं कर सकते? मिंगव सेटअप बल्कि खास है।

संपादित करें: मैं देखूंगा कि क्या मैं mingw-w64 के साथ इलेक्ट्रा बिल्ड प्राप्त कर सकता हूं, इसलिए मुझे टन i686 libs स्थापित करने की आवश्यकता नहीं है।

समस्या यह है कि मेरे पास एक अतिरिक्त जेसी मशीन नहीं है और मट्ठा का मिंगव सी ++ 11 नहीं जानता है।

मैं mingw-w64 काम करने में कामयाब रहा। हालांकि std::mutex उपलब्ध नहीं है क्योंकि विंडोज़ पर कोई glibc नहीं है और std::mutex pthreads पर निर्भर करता है। कोई विचार?

वाह धन्यवाद!

क्या यह संकलन त्रुटि की ओर जाता है? आंतरिक के लिए std :: mutex का उपयोग नहीं किया जाता है
कार्यक्षमता, लेकिन केवल उपयोगकर्ता द्वारा शामिल की जाने वाली हेडर फ़ाइल में। इसका प्रयोग किया जाता है
हालांकि परीक्षण के मामलों में।

संकलन समस्याओं का एक समाधान mingw . में एक std::mutex प्रदान करना है
लॉक/अनलॉक करने के हर प्रयास पर केस थ्रोइंग सिस्टम त्रुटियाँ। असल में, मैं
मिंगव लोगों से कम से कम ऐसा कुछ प्रदान करने की अपेक्षा करें (उदाहरण के लिए जब
कुछ मैक्रो सेट किया गया है, -D_GLIBCXX_USE_NANOSLEEP के समान)

https://github.com/meganz/mingw-std-threads दूसरा तरीका हो सकता है। लेकिन वह है
सबसे अधिक संभावना केवल तभी उपयोगी होती है जब सभी परीक्षण मामलों को छोड़कर जिनमें शामिल हैं std::mutex
पहले से ही चल रहा है।

मूल रूप से, यह C++11 का केवल एक उदाहरण है जो ठीक से उपलब्ध नहीं है।

मिंगव स्थिति अभी:

• libloader में बाहरी प्रोजेक्ट के रूप में dlfcn-win32 जोड़ा गया। इस तरह सेमेक चेक आउट + लाइब्रेरी को एक अतिरिक्त बिल्ड चरण के रूप में संकलित करता है। मैं अतिरिक्त dll विवरण से बचने के लिए संग्रह को लिंक कर रहा हूँ।
• cpp11_benchmark_thread पर winock2.h/ws2_32.dll निर्भरता जोड़ा गया। gethostname द्वारा आवश्यक () - कॉल

अभी मैं -static-libgcc + -static-libstdc++ साथ निर्माण कर रहा हूं। अन्यथा शराब डीएलएस नहीं ढूंढ पा रही है। अतिरिक्त म्यूटेक्स या तो संकलित नहीं करता है। मैंने मिंगव-एसटीडी-थ्रेड्स की कोशिश की। बस अधिक संकलन त्रुटियां मिलीं :-)

अगर मैं x86_64-w64-mingw32-X से x86_64-w64-mingw32-X-posix स्विच करता हूं तो std::mutex ठीक संकलित करता है, क्योंकि pthread सामग्री परिभाषित की जाती है। हालांकि मुझे libwinpthread-1.dll पर एक अतिरिक्त निर्भरता मिलती है, जो शराब नहीं ढूंढ पा रही है।

मुझे लगता है कि हमारी सबसे अच्छी शर्त x86_64-w64-mingw32-X-posix का उपयोग कर रही है।

फिर से, मुझे आश्चर्य है कि आपको भी यह समस्या है। अब तक हम खुश थे जब हमें एक libelektra.dll मिला।

मैं इस x86_64-w64-mingw32-X-posix निर्णय के बारे में कुछ नहीं कह सकता, क्योंकि मैं इसका उपयोग नहीं करता और इसके निहितार्थों को नहीं जानता। मैं सोच रहा हूं कि ऐसा पॉज़िक्स-लिब भी मौजूद है, मैंने सोचा था कि पॉज़िक्स-लेयर दृष्टिकोण साइगविन है न कि मिंगव।

क्या इस निर्णय का भी libelektra.dll पर कोई प्रभाव पड़ता है? यदि यह केवल परीक्षण मामलों के लिए है, तो कोई भी परवाह नहीं करेगा (जब तक कि बिल्ड सर्वर इसे चलाने में सक्षम हो)। यदि परीक्षण के मामले चलते हैं, तो यह एक बड़ा लाभ होगा। (देखें #270 जहां यूनिट परीक्षणों ने मैक ओएस एक्स पर कुछ अजीब बग का खुलासा किया)

ऐसा लगता है कि libwinpthread-1.dll डाउनलोड किया जा सकता है, मुझे नहीं पता कि वे शराब के साथ काम करते हैं या नहीं? क्या आप इसे बाहरी प्रोजेक्ट के रूप में भी जोड़ सकते हैं जैसे dlfcn-win32 के साथ किया गया (ताकि सभी डीएलएस एक ही तरह से संभाले जा सकें)? अन्यथा, यदि आपको परीक्षणों के लिए 1 या 3 डीएलएस डाउनलोड करने की आवश्यकता है तो वास्तव में कोई फर्क नहीं पड़ता (फिर से, मैं कोई उपयोगकर्ता नहीं हूं, और विंडोज़ डीएलएस की तैनाती अवधारणा को समझ नहीं पा रहा हूं)।

@beku आपको क्या लगता है? क्या आपके पास oyranos के साथ विंडोज़ पर हमारे नवीनतम 0.8.13 mingw-w64 बिल्ड का परीक्षण करने का समय है?

क्या मिंगव बिल्ड जॉब के लिए आमतौर पर परीक्षण सक्षम होते हैं? कल ये सभी विकलांग थे।

हाँ, वे विकलांग थे। लेकिन cpp11_benchmark_thread जैसे afaik उदाहरण/बेंचमार्क भी अक्षम कर दिए गए थे। तो मैंने सोचा कि आपने इसे बदल दिया है और पहले की तुलना में अधिक संकलित किया है।

मैंने पूरे रेपो को सी ++ 11 सक्षम के साथ संकलित किया। और कुछ नहीं।

लेकिन जब तक आप बिन निर्देशिका में आवश्यक डीएलएस की प्रतिलिपि बनाते हैं (आरपीएटी नहीं होने के लिए धन्यवाद विंडोज़)। मुझे कोई रास्ता नहीं मिला है a) cmake को dll डायरेक्टरी + b) पॉइंट वाइन को dll डायरेक्टरी में खोजने दें।
मैंने सोचा था कि स्थिर लिंकिंग काम करेगी लेकिन फिर निर्माण इलेक्ट्रा डीएल को जोड़ने के दौरान डुप्लिकेट प्रतीकों के साथ विफल हो जाता है। क्योंकि डीएलएल में पहले से ही प्रतीक शामिल हैं।

@ मार्कस 2330 मैं इलेक्ट्रा प्राप्त करने में कामयाब रहा + बिना किसी डीएलएस की नकल किए शराब के साथ चल रहा था। चाल हमेशा निष्पादन योग्य और साझा वस्तुओं ( CMAKE_SHARED_LINKER_FLAGS / CMAKE_EXE_LINKER_FLAGS => " -static ") के लिए स्थिर लिंकिंग को सक्षम करना है।

डुप्लिकेट किए गए प्रतीकों के आसपास काम करने के लिए मैंने libelektra और libelektratools के लिए संस्करण-स्क्रिप्ट जोड़े हैं। इस तरह केवल हमारे प्रतीकों का निर्यात किया जाता है।

यह वास्तव में ठीक काम करता है। जैसे

$ wine64 ./bin/kdb-static.exe
Usage: Z:\home\manuel\build\bin\kdb-static.exe <command> [args]

Z:\home\manuel\build\bin\kdb-static.exe is a program to manage elektra's key database.
Run a command with -H or --help as args to show a help text for
a specific command.

Known commands are:
check   Do some basic checks on a plugin.
convert Convert configuration.
cp      Copy keys within the key database.
export  Export configuration from the key database.
file    Prints the file where a key is located.
fstab   Create a new fstab entry.
get     Get the value of an individual key.
[...]

$ wine64 bin/cpp_example_iter.exe
user/key3/1
user/key3/2
user/key3/3

यहां तक ​​कि bin/cpp11_benchmark_thread.exe भी काम करता है।

अन्य चीजें बस दुर्घटनाग्रस्त हो जाती हैं:

$ wine64 ./bin/kdb-static.exe get
wine: Unhandled page fault on read access to 0x00000000 at address 0x7fd0e8b62c8a (thread 0009), starting debugger...
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00007fd0e8b62c8a).
Register dump:
 rip:00007fd0e8b62c8a rsp:000000000033f428 rbp:0000000000000000 eflags:00010293 (  R- --  I S -A- -C)
 rax:0000000000000000 rbx:000000000033f700 rcx:0000000000000000 rdx:000000000033f5b0
 rsi:0000000000000000 rdi:0000000000000000  r8:0000000000000000  r9:0000000000000072 r10:0000000000000000
 r11:000000000003f615 r12:000000000033f5b0 r13:00000000000373b0 r14:0000000000000000 r15:000000000033f930
Stack dump:
0x000000000033f428:  00007fd0e748ea93 0000000000000000
0x000000000033f438:  0000000000000000 0000000000000000
0x000000000033f448:  0000000000000028 0000000000010020
0x000000000033f458:  8d98315017c96400 6f46746547485300
0x000000000033f468:  687461507265646c 0000000000000000
0x000000000033f478:  0000000000000000 0000000000000000
0x000000000033f488:  000000000003fab0 0000000000030000
0x000000000033f498:  8d98315017c96400 6f46746547485300
0x000000000033f4a8:  687461507265646c 0000000000000000
0x000000000033f4b8:  0000000000000000 0000000000000000
0x000000000033f4c8:  0000000000000000 0000000000000000
0x000000000033f4d8:  0000000000000000 0000000000000000
Backtrace:
=>0 0x00007fd0e8b62c8a strlen+0x2a() in libc.so.6 (0x0000000000000000)
  1 0x00007fd0e748ea93 MSVCRT_stat64+0x92() in msvcrt (0x0000000000000000)
  2 0x00000000004744af in kdb-static (+0x744ae) (0x000000000003f9d0)
  3 0x000000000043bda5 in kdb-static (+0x3bda4) (0x000000000003f9d0)
  4 0x0000000000431d76 in kdb-static (+0x31d75) (0x00000000000360a0)
[...]

अभी मैंने अन्य कंपाइलरों के बारे में सोचे बिना केवल संस्करण-स्क्रिप्ट सामग्री जोड़ दी है। क्या मुझे अपना काम जारी रखना चाहिए या दिलचस्पी नहीं है?

src/plugins/wresolver/wresolver.c में क्रैश क्योंकि pk->filename NULL है

पीके प्रकार का है resolverHandles.user

मैंने प्लगइन पर एक नज़र डालने की कोशिश की लेकिन मैं फॉर-लूप को समझने में विफल रहा elektraWresolverOpen । लूप कॉल करता है elektraWresolveFileName -> elektraResolve{Spec,Dir,User,System} जो सभी malloc resolverHandle->filename और उसके लिए रिसाव स्मृति।

यह बात बताने के लिए धन्यवाद! c87ae8e87a716b02b2c7ed790ad56a89d95547a9 में परिचय के बाद से कोड स्पष्ट रूप से टूटा हुआ है
केवल और हमेशा लूपिंग के दौरान सिस्टम हैंडल को इनिशियलाइज़ किया गया था। जब किसी अन्य नेमस्पेस का उपयोग किया जाता है तो यह क्रैश हो जाता है।

मैंने इसे ठीक किया
edb4d50856bb5331749220de5a83fa2062624a9d

काम जारी रखने के बारे में: एक तरफ संकलित सामग्री भी चले तो अच्छा होगा। दूसरी ओर, रिलीज इस सप्ताह के अंत में होनी चाहिए, इसलिए एक पुल अनुरोध जल्द ही महत्वपूर्ण होगा (कम से कम एक संक्षिप्त फीडबैक सर्कल का मौका होना चाहिए, उदाहरण के लिए संस्करण-स्क्रिप्ट वास्तव में क्या करती है)

लेकिन यह पर्याप्त है अगर केवल एक संस्करण (स्थिर संकलन) काम करता है। केडीबी-टूल को चालू देखकर बहुत अच्छा लगा!

मुझे edb4d50856bb5331749220de5a83fa2062624a9d कहां मिल सकता है?

edb4d50856bb5331749220de5a83fa2062624a9d को थोड़ी देर बाद आगे बढ़ाया गया।

डेबियन-अस्थिर-मिमी पर कौन से जीसीसी संस्करण स्थापित हैं?

http://build.libelektra.org :8080/job/elektra-multiconfig-gcc-unstable/build_type=Release,gcc_version=5.2,plugins=ALL/56/console

कहते हैं कि कोई gcc-5.2 . नहीं है

क्या आप अधिक से अधिक संकलक स्थापित कर सकते हैं, कृपया?

किसी मुद्दे या पीआर में मैंने कहा है कि मैंने नवीनतम को छोड़कर सभी कंपाइलरों को हटा दिया है।
संपादित करें: स्थिर पर जीसीसी 4.9, अस्थिर पर 4.9 + 5.x (डिफ़ॉल्ट)

कृपया अपने स्वयं के कंटेनरों पर इस प्रकार के परीक्षण करें (मुझे वे वैसे भी अत्यधिक अनावश्यक लगते हैं)। मेरा वैसे भी हमेशा के लिए नहीं रहेगा।

मैंने वह नहीं पढ़ा है। उनके पास शायद 50MB प्रत्येक है। क्या आप कृपया उन्हें फिर से स्थापित कर सकते हैं और पहले प्रश्न का उत्तर दे सकते हैं?

शायद मैंने आपको हमारी मुलाकात में बताया था। लेकिन मैंने आपको निश्चित रूप से बताया है।

debian-unstable:~ # gcc -v 2>&1 | tail -n 1
gcc version 5.2.1 20150903 (Debian 5.2.1-16)

संस्करण विशिष्ट बाइनरी को जीसीसी-5 कहा जाता है। छोटे संस्करणों के लिए अब कोई अलग पैकेज नहीं है। तो इस स्तर के विवरण के साथ आपका मल्टीकॉन्फिग-जीसीसी अप्रचलित है। मैं जीसीसी 4.7 को हटाने और जीसीसी-5.2 को जीसीसी -5 के साथ बदलने की सलाह देता हूं और किया जाता है।

एकमात्र अतिरिक्त कंपाइलर उपलब्ध है जिसे मैंने इंस्टॉल नहीं किया है वह है gcc-4.8.1। और gcc-4.8 को हटाने के लिए पहले ही टैग किया जा चुका है।

जानकारी के लिए धन्यवाद! ऐसा लगता है कि कई उपलब्ध कंपाइलरों के गौरव के दिन खत्म हो गए हैं।

मैंने मल्टीकॉन्फिग-अस्थिर को ठीक किया।

मैं अभी के लिए बंद करूँगा, उत्कृष्ट एजेंट सेटअप के लिए धन्यवाद।

हैलो, जेसी (स्थिर) को कुछ और पैकेज चाहिए। क्या आप कृपया स्थापित कर सकते हैं:

• [ ] फेकरूट
• [ ] gpg (+ Autobuilder [email protected] के लिए कुंजी बनाएं)
• [ ] reprepro (शायद पहले से ही स्थापित है, स्क्रिप्ट इतनी दूर नहीं गई)

फ़ेकरूट स्थापित, gpg + repropro पहले से ही स्थापित है।
क्या आप मुझे अपनी पहले से मौजूद gpg कुंजी मेल कर सकते हैं? तो दोनों निर्माण मशीनों में समान है

अलग-अलग gpg कुंजियाँ रखना ठीक है। मुझे यकीन नहीं है कि वर्तमान सेटअप उनका उपयोग करता है, इसलिए पहले प्रतीक्षा करें यदि http://build.libelektra.org :8080/job/elektra-git-buildpackage-jessie/2/ विफल रहता है।

• debhelper + libsystemd-journal-dev स्थापित
• पायथन-देव एक गलत निर्भरता है। यह python2.7-dev या python3-dev या दोनों होना चाहिए
• हमें अजगर-समर्थन की आवश्यकता क्यों है?

स्थापना के लिए धन्यवाद!

python-dev जेसी के लिए उपलब्ध है, और python-support भी। कृपया उन्हें स्थापित करें।

मैंने इसे स्थानीय रूप से परीक्षण किया, जब ये पैकेज स्थापित होते हैं, तो यह जेसी के लिए बनाता है।

ज़रूर, यह उपलब्ध है लेकिन यह एक गलत निर्भरता है। अजगर-देव अजगर 2.7-देव पर निर्भर करता है जो _not_ पर्याप्त है। इसके बजाय python2.7-dev + python3-dev की आवश्यकता है।

सभी इम्हो पर पायथन-समर्थन की आवश्यकता नहीं है।

मुझे नहीं पता कि निर्भरताओं को इस तरह क्यों चुना गया था, अधिकांश पैकेजिंग जीएसओसी के दौरान @iandonnelly द्वारा की गई थी।

हाँ, पैकेज को भी python3 बाइंडिंग बनाने के लिए अद्यतन किया जाना चाहिए। वर्तमान में, यह बस नहीं किया गया है। फिर भी, आप python3-dev इंस्टॉल कर सकते हैं, ताकि बिल्ड टूट न जाए (जब python3 बाइंडिंग + प्लगइन्स डेबियन पैकेज में जोड़े जाते हैं)।

इसका मतलब यह नहीं है कि वे सही हैं :-) - मैं अजगर-देव डिपो के बारे में काफी निश्चित हूं।
क्या आप कृपया उन्हें बदल सकते हैं और अजगर-समर्थन डिपो को हटा सकते हैं?

python3-dev और python2.7-dev पहले से ही स्थापित है। अन्यथा कोई बंधन नहीं बनेगा।

बीटीडब्ल्यू। @pinotree का आधिकारिक डेबियन पैकेज केवल @pinotree का काम बेहतर है।

जब मुझे समय मिलेगा, तो मैं अपनी "डेबियन" शाखा को अपडेट करूंगा कि

मैंने कभी नहीं कहा कि मैं python2 पैकेज हटा दूंगा। मैं केवल इतना कह रहा हूं कि अजगर-देव एक गलत निर्भरता है। हमें स्पष्ट संस्करणों की आवश्यकता है। तो pythonX-dev उपयोग करने के लिए सही डिपो है।

उम्मीद है कि पिनोट्री ने निर्भरता को सही ढंग से पूरा किया।

बीटीडब्ल्यू, चीता मर चुका है। इसका इस्तेमाल न करें।

ठीक है, इसे बदल दिया। कृपया b7c266b36b0ab0fad9120e67a457b580c7c44690 को वापस लाएं और यदि आवश्यक हो तो अजगर-समर्थन स्थापित करें।

मुझे यकीन है कि पिनोट्री ने इसे सही तरीके से किया है;)

और यह कहता है: dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
http://community.markus-raab.org :8080/job/elektra-git-buildpackage-jessie/3/console

स्थापित

पायथन-देव एक गलत निर्भरता है। यह python2.7-dev या python3-dev या दोनों होना चाहिए

• python-dev डिफ़ॉल्ट पायथन 2 संस्करण के लिए विकास पैकेज स्थापित करता है; व्हीजी के बाद से, यह पायथन 2.7 . है
• python3-dev डिफ़ॉल्ट पायथन 3 संस्करण के लिए विकास पैकेज स्थापित करता है; व्हीजी में पायथन 3.2, जेसी में 3.4, और अब तक स्ट्रेच में 3.4 (मुझे लगता है कि जल्द ही 3.5 हो जाएगा)

इसलिए, यदि आप डिफ़ॉल्ट पायथन 2/3 संस्करण के खिलाफ निर्माण करना चाहते हैं, तो क्रमशः python-dev / python3-dev , न कि pythonX.Y-dev संस्करण (जिसे आपको स्पष्ट रूप से उपयोग करने की आवश्यकता है) एक सटीक पायथन संस्करण स्थापित करना चाहते हैं, भले ही सिस्टम पर केवल एक ही स्थापित न हो, और डिफ़ॉल्ट वाला न हो)। मैं जो अनुशंसा करता हूं उसका उपयोग करना।

python-dev विवरण:
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

इस पाठ के अनुसार अजगर-देव निश्चित रूप से जल्द ही कुछ समय के लिए अजगर 3 पर निर्भर हो सकता है

इसके अलावा और अधिक: एक और पायथन 2 संस्करण कभी नहीं होगा। तो python2.7-dev अब तक का आखिरी python2 dev पैकेज होगा।

मैंने जो कहा वह Python3-dev के आधार पर है।

अब केवल चाबी गायब है:

gpg: new configuration file `/home/jenkins/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/jenkins/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/jenkins/.gnupg/secring.gpg' created
gpg: keyring `/home/jenkins/.gnupg/pubring.gpg' created
gpg: skipped "Autobuilder <[email protected]>": secret key not available
gpg: /tmp/debsign.DlSdnFtB/elektra_0.8.13-1.41.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting....

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/08C91995 2015-09-30
      Key fingerprint = BA4C 688E 9071 FD3F 57ED  E9D6 D0A9 EDB9 08C9 1995
uid                  Autobuilder <[email protected]>
sub   2048R/E69F110A 2015-09-30

किया हुआ

शुक्रिया!

कृपया निर्यात/होम/जेनकींस/भंडार http के माध्यम से।

cannot access /home/jenkins/repository: No such file or directory ?

→ http://194.117.254.29/इलेक्ट्रा-स्थिर/

@manuelm क्या आप एजेंटों पर ronn स्थापित कर सकते हैं? (मैन पेज बनाने के लिए आवश्यक)

apt-get install ruby-ronn

किया हुआ

धन्यवाद, जेसी पैकेज फिर से बनते हैं, और मैन पेज अब शामिल हैं!

कृपया musl स्थापित करें, अर्थात

apt-get install musl musl-dev musl-tools

शुक्रिया!

musl स्थापित और एजेंटों को उन्नत किया गया

बिल्ड सर्वर के बारे में दो महत्वपूर्ण बातें:

1. नई खाली नौकरियां न बनाएं, बल्कि डुप्लिकेट करें, उनकी सही सेटिंग्स हैं (नंबर 2 में उल्लिखित को छोड़कर)।
2. हमें संदर्भ क्लोन (इन/होम/जेनकिंस/लिबेलेक्ट्रा) का उपयोग करना चाहिए या प्रत्येक बिल्ड-जॉब के लिए उथले क्लोन पसंद करना चाहिए (वर्तमान में केवल कुछ के लिए किया जाता है, जैसे इलेक्ट्रा-क्लैंग)। वर्तमान में कई अनावश्यक पुनरावृत्तियों के कारण आवागमन> 300MB है।

@mpranj यह बहुत अच्छा होगा यदि आप 2 को ठीक कर सकते हैं।

@ मार्कस 2330 बस यह सुनिश्चित करने के लिए: मुझे सभी निर्माण नौकरियों के लिए समान क्लोन व्यवहार लागू करना चाहिए जैसे कि यह elektra-clang ?

निम्न को छोड़कर सभी बिल्ड-नौकरियों पर लागू उथले क्लोन:

• [ ] इलेक्ट्रा-गिट-बिल्डपैकेज-जेसी
• [ ] इलेक्ट्रा-गिट-बिल्डपैकेज-व्हीज़ी
• [ ] इलेक्ट्रा-मल्टीकॉन्फिग-जीसीसी-स्थिर
• [ ] इलेक्ट्रा-मल्टीकॉन्फिग-जीसीसी-अस्थिर
• [ ] इलेक्ट्रा-स्रोत-पैकेज-परीक्षण

ये नौकरियां कुछ उप-निर्देशिका की जांच करती हैं। सुनिश्चित नहीं था कि आप वहाँ क्या चाहते हैं इसलिए मैं उन्हें वैसे ही छोड़ दूँगा जैसे वे अभी के लिए हैं।

शुक्रिया! हां, उन्हें पूरे इतिहास और शाखाओं की जरूरत है, उथले क्लोनों का कोई मतलब नहीं है लेकिन संदर्भ क्लोन भंडार उपयोगी होगा।

जेनकिंस को 1.651.2 पर अपडेट किया गया। साथ ही सभी प्लगइन्स को अपडेट किया गया।

मैं संदर्भ क्लोन रेपो के लिए इस मुद्दे को खुला रखूंगा। हमारे पास "क्रॉन जॉब्स" भी होना चाहिए जो समय-समय पर रेपो को अपडेट करते हैं, आदर्श रूप से जेनकींस का उपयोग करते हुए।

जेनकिंस ने कुछ नौकरियों का निर्माण बंद कर दिया (स्पष्ट रूप से अद्यतन के बाद से)। यह विफल रहता है
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

जानकारी के लिए धन्यवाद। मैं 1.31 से 1.14 तक जीथब अनुरोध बिल्डर को डाउनग्रेड करने का प्रयास करता हूं।

जीथब कमिट के लिए बिल्ड स्टेटस सेट करते समय अब ​​यह अटका हुआ लगता है। यह चेतावनी देता है कि यह config में पदावनत है।

मैंने प्रत्येक प्लगइन को उसके नाम पर *git* साथ डाउनग्रेड करने का भी प्रयास किया, लेकिन फिर भी त्रुटियां थीं (मेलर प्लगइन से संबंधित अजीब त्रुटि, मेलर प्लगइन के डाउनग्रेड ने मदद नहीं की)। इसलिए मैंने सब कुछ हाल के संस्करणों में फिर से अपडेट किया। समस्या एक ज्ञात समस्या अपस्ट्रीम प्रतीत होती है:

https://github.com/janinko/ghprb/issues/347

मुझे उम्मीद है कि वे इसे जल्द ही ठीक कर देंगे।

एक और सवाल: क्या कोई जानता है कि हर पीआर के लिए कई नौकरियां कैसे चलाई जाती हैं? (मैं इलेक्ट्रा-विलय-अनुरोध-स्थिर और इलेक्ट्रा-विलय अनुरोध-अस्थिर दोनों को चलाना चाहूंगा)

पैरामीटरयुक्त बिल्ड के साथ elektra-test-bindings जॉब ठीक काम कर रहा है (जैसा कि अपस्ट्रीम टिकट में भी वर्णित है)। क्या हम इसे सिर्फ पैरामीटरयुक्त बिल्ड में नहीं बदल सकते? बग को कुछ समय के लिए अपस्ट्रीम में रिपोर्ट किया गया है, मुझे नहीं लगता कि यह जल्द ही ठीक हो जाएगा।

अच्छा विचार है, हम सभी पीआर नौकरियों को पैरामीटरयुक्त बिल्ड में बदल सकते हैं, इसके वास्तव में केवल फायदे हैं। यह हमें एक शाखा निर्दिष्ट करके भी मैन्युअल रूप से कार्य चलाने की अनुमति देता है। और इसका उपयोग नियमित निर्माण नौकरियों के लिए भी किया जा सकता है।

आदर्श रूप से, प्रत्येक कार्य को जीथब पीआर द्वारा भी निष्पादित किया जा सकता है। (विशेष रूप से गैर-पीआर कार्यों के लिए जो मास्टर शाखा के दस्तावेज़ या कवरेज को अद्यतन करते हैं) को छोड़कर

इलेक्ट्रा-टेस्ट-बाइंडिंग 'कॉन्फ़िगरेशन का एक नुकसान यह है कि यह केवल मतदान करता है और इसके निर्माण शुरू होने तक (5 मिनट तक) काफी लंबा समय लगता है। मैं "बिल्ड ट्रिगरिंग के लिए जीथब हुक का उपयोग करें" को सक्रिय नहीं करना चाहता, हालांकि, बिल्ड जॉब को तोड़ने के लिए नहीं।

बीटीडब्ल्यू। क्या आप सुनिश्चित हैं कि "उथला क्लोन" विकल्प जीथब पुलरेक्वेस्ट बिल्डर नौकरियों के लिए ठीक है?

मुझे आश्चर्य है कि जीथब नए पीआर के लिए उपयोग की जाने वाली बिल्ड जॉब को कैसे चुनता है। इलेक्ट्रा-टेस्ट-बाइंडिंग और इलेक्ट्रा-इन-मर्जरेक्वेस्ट को नए पीआर के लिए कभी क्यों नहीं चुना जाता है? यह कभी-कभी इलेक्ट्रा-विलय-अनुरोध-अस्थिर और कभी-कभी इलेक्ट्रा-विलय अनुरोध (-स्थिर) क्यों होता है?

@manuelm क्या आपके पास कोई विचार है?

बीटीडब्ल्यू। किसी भी तरह से तैयार निर्माण नौकरियों और जीथब का संचार गंभीर रूप से खराब है (यहां तक ​​​​कि इलेक्ट्रा-टेस्ट-बाइंडिंग के लिए भी)। अब यह लगभग हर निर्माण पर कहता है "कुछ जांच अभी तक पूरी नहीं हुई हैं"।

इलेक्ट्रा-टेस्ट-बाइंडिंग 'कॉन्फ़िगरेशन का एक नुकसान यह है कि यह केवल मतदान करता है और इसके निर्माण शुरू होने तक (5 मिनट तक) काफी लंबा समय लगता है।

और यह एक समस्या है क्योंकि? वैसे भी परीक्षण में 5 मिनट से अधिक समय लगता है।

इलेक्ट्रा-टेस्ट-बाइंडिंग और इलेक्ट्रा-इन-मर्जरेक्वेस्ट को नए पीआर के लिए कभी क्यों नहीं चुना जाता है?

यह क्यों चाहिए? elektra-test-bindings केवल "ट्रिगर वाक्यांश" से ट्रिगर होता है। पता नहीं elektra-ini-mergerequests है।

यह कभी-कभी इलेक्ट्रा-विलय-अनुरोध-अस्थिर और कभी-कभी इलेक्ट्रा-विलय-अनुरोध-स्थिर क्यों होता है?

-स्थिर/-अस्थिर नए हैं? मुझे यकीन नहीं है कि प्रति नए पीआर में कई नौकरियों को ट्रिगर करना संभव है। मैं सबजॉब करूंगा।

बीटीडब्ल्यू मैंने इसे पहले ही कुछ बार कहा है लेकिन मुझे लगता है कि नौकरियों की मात्रा हास्यास्पद हो रही है और एक गड़बड़ कॉन्फ़िगरेशन का संकेत है। लेकिन किसी चीज को सुलझाने की तुलना में आलोचना करना हमेशा आसान होता है।

5 मिनट एक समस्या है जब आप बिल्ड सर्वर को डीबग करना चाहते हैं। और मुझे अब भी उम्मीद है कि हमें लगभग 5 मिनट का समय लेते हुए एक त्वरित पहला परीक्षण मिलेगा।

आह, ठीक है, मैंने "ट्रिगर बनाने के लिए केवल ट्रिगर वाक्यांश का उपयोग करें" विकल्प को याद किया। जीथब अनुरोध निर्माता के लिए विन्यास वास्तव में एक गड़बड़ है।

किसी ने जीथब परियोजनाओं के बारे में बात की जहां उनके पास प्रत्येक पीआर के लिए कई नौकरियां चल रही हैं। (व्यक्तिगत रूप से प्रदर्शित)

एक सबजॉब क्या है? क्या आपका मतलब मल्टीजॉब है ?

किसी ने जीथब परियोजनाओं के बारे में बात की जहां उनके पास प्रत्येक पीआर के लिए कई नौकरियां चल रही हैं। (व्यक्तिगत रूप से प्रदर्शित)

आपको जीथब पर दो सेवाओं को जोड़ना होगा।

एक सबजॉब क्या है? क्या आपका मतलब मल्टीजॉब है?

हाँ मल्टीजॉब।

बीटीडब्ल्यू, https://docs.travis-ci.com/ के बारे में क्या? ट्रैविस के पास OSX के लिए समर्थन है।

मुझे पता है कि यह जेनकींस को प्रतिस्थापित नहीं करेगा लेकिन पीआर/हर प्रतिबद्ध निर्माण पर प्रतिस्थापित कर सकता है। जेनकींस अभी भी एकाधिक कंपाइलर/आदि .. परीक्षण कर सकता है।
संपादित करें: ट्रैविस में जीसीसी + क्लैंग भी है।

सहमत, उनकी सीपीयू शक्ति/बिजली का मुफ्त में उपयोग करना दिलचस्प होगा क्योंकि इलेक्ट्रा खुला स्रोत है।

यह संभावना है कि जीथब और जेनकींस के बीच का संबंध वास्तव में 1:1 है। जीथब सेवा में मैंने http://build.libelektra.org :8080/github-webhook/ दर्ज किया और मुझे जेनकींस में एक और यूआरएल बनाने का कोई तरीका नहीं मिला। (मुझे केवल ओवरराइड निर्दिष्ट करने का एक तरीका मिला, लेकिन इसने एक नया URL नहीं बनाया)।

https://github.com/janinko/ghprb/issues/142 में वे चर्चा करते हैं कि इसे "बस काम करना चाहिए"? (कई सेवाओं को जोड़े बिना)

हालाँकि, sha1 समस्या को अब हल किया जाना चाहिए। यह टूट गया था क्योंकि जेनकिंस ने एक नया सुरक्षा माप पेश किया था जो अज्ञात पर्यावरण चर को छांटता है। मैं सुझाव (जोड़ा -Dhudson.model.ParametersAction.safeParameters = ghprbActualCommit, ghprbActualCommitAuthor, ghprbActualCommitAuthorEmail, ghprbAuthorRepoGitUrl, ghprbCommentBody, ghprbCredentialsId, ghprbGhRepository, ghprbPullAuthorEmail, ghprbPullAuthorLogin, ghprbPullAuthorLoginMention, ghprbPullDescription, ghprbPullId, ghprbPullLink, ghprbPullLongDescription, ghprbPullTitle, ghprbSourceBranch, ghprbTargetBranch के रूप में यह तय हो गई, ghprbTriggerAuthor,ghprbTriggerAuthorईमेल,ghprbTriggerAuthorLogin,ghprbTriggerAuthorLoginMention,GIT_BRANCH,sha1 to /etc/default/jenkins)।

अतिरिक्त बिल्ड सर्वर के उपयोग के बारे में: हाँ, आगे बढ़ें। यह एक पीआर के लिए कई बिल्ड जॉब्स के मुद्दे को भी हल करता है;) मैंने कभी भी ट्रैविस-सीआई का इस्तेमाल नहीं किया, इसलिए इसके बारे में कुछ भी नहीं कह सकता। मैंने अनुमति दी है कि ट्रैविस के पास ElektraInitiative तक पहुंच है।

पहला ट्रैविस बिल्ड: https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
मुझे लगता है कि हमें कुछ yaml फ़ाइल की आवश्यकता है ताकि ट्रैविस को पता चले कि क्या करना है।

और मुझे पता चला कि प्रति पीआर में कई जेनकिंस जॉब कैसे करें, हर बिल्ड-जॉब के लिए एक अलग संदर्भ की जरूरत थी। अगली बैठक में हम चर्चा करते हैं कि "तेज" और अन्य निर्माण कार्यों को क्या करना चाहिए।

मैं ट्रैविस पर काम कर रहा हूं (या कुछ चीजों की जांच कर रहा हूं)

मज़े करो। ट्रैविस ने एक जीथब सेवा भी जोड़ी है, इसलिए मुझे लगता है कि ट्रैविस के साथ एक पीआर भी बनाया जाएगा।

मैं पहले से ही ज़ोर ज़ोर से कसम खा रहा हूँ

-- जेएनआई नहीं मिला (लापता: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
-- प्लगइन jni को बाहर करें क्योंकि jni नहीं मिला

मैं जावा प्लगइन को सही ढंग से कॉन्फ़िगर करने में असमर्थ हूं। हालांकि जावा बाइंडिंग काम करते हैं। डेबियन अस्थिर पर। कोई विचार? सेमेक मॉड्यूल को देखने से ज्यादा मदद नहीं मिलती है।

संपादित करें: /usr/lib/jvm/java-8-openjdk-amd64/include/linux/jni_md.h , /usr/lib/jvm/java-8-openjdk-amd64/include/jawt.h और /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h जगह पर है

संपादित करें 2: समझ गया। JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/ ....

https://travis-ci.org/manuelm/libelektra/builds/130638376

डेबियन अस्थिर एक डॉकटर कंटेनर के भीतर बनाया गया। लेकिन निर्माण में उम्र लगती है।
कोई अच्छा विचार?

क्लैंग अक्सर निर्माण समय के संबंध में तेज़ होता है, लेकिन मुझे लगता है कि निर्भरताओं की स्थापना में बड़ी मात्रा में समय लगता है

क्या कोई अधिक न्यूनतम डेबियन डॉकर छवि नहीं है, जिसका उपयोग किया जाता है? ऐसा लगता है कि बहुत सारे पैकेज स्थापित हो गए हैं जिनकी आवश्यकता नहीं होनी चाहिए।

@sirblackheart आपको https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm शायद डिस्ट-अपग्रेड। बहुत सारे पैकेज अपडेट हो जाते हैं जो कि वेलैंड की तरह डेस्कटॉप विशिष्ट होते हैं

नहीं, जिला उन्नयन छोटा है। शायद एक मिनट। बिल्ड डिपो को स्थापित करने में लगभग 50% समय लगता है।

मैं अभी बिल्ड इमेज को hub.docker.com पर धकेल रहा हूं। उम्मीद है कि इससे चीजों में तेजी आएगी। लेकिन छवि में 1.9gb . है

बीता हुआ समय 14 मिनट 8 सेकंड

यकीन नहीं होता कि हम बहुत बेहतर कर सकते हैं

जैसा मैंने कहा, क्लैंग शायद हमें 2-3 मिनट का समय दे। कम से कम यह aseprite परियोजना के लिए करता है
https://travis-ci.org/aseprite/aseprite

वैसे भी दोनों कंपाइलर्स रखना उपयोगी होगा।

कार्य सामग्री तैयार करते समय बस एक विचार था: क्या होगा यदि हम पुश अनुरोध में सभी कामों के पथ निकाल दें और बाइंडिंग/प्लगइन्स केवल तभी प्रभावित हों जब वे प्रभावित हों? जैसे

• cmake/* में परिवर्तन सब कुछ ट्रिगर करता है (प्लगइन्स + बाइंडिंग)
• स्रोत/बाइंडिंग/फू में परिवर्तन बाध्यकारी फू ट्रिगर करता है
• src/plugins/foo ट्रिगर्स प्लगइन foo में परिवर्तन
• सब कुछ में परिवर्तन किसी भी प्लगइन्स + बाइंडिंग को संकलित नहीं करता है

हमारे पास अभी भी दैनिक/दिन में दो बार जेनकींस पर पूर्ण निर्माण है।

@manuelm अच्छा विचार, @ टॉम-वा ऐसी स्क्रिप्ट लिखेंगे, क्या आप इसके लिए एक नया मुद्दा बना सकते हैं?

@mpranj : रिमाइंडर: ट्रैविस में मैक ओएस एक्स बिल्ड जोड़ें और पीआर में मिंगव बिल्ड जोड़ें। (* बीएसडी अधिक प्रयास लगता है)

@ मार्कस 2330 अब मैं समझता हूं @ मैनुअल डॉकर दृष्टिकोण, ट्रैविस अगले साल तक ubuntu 16.04 का समर्थन नहीं करेगा, इसलिए सभी निर्भरता प्राप्त करने के लिए डॉकर की आवश्यकता है कि ubuntu 14.04 में = swig3.0 libsystemd-devel नहीं है।

मुझे खेद है कि मैं आज बैठक में शामिल नहीं हो सका। कार्यस्थल पर हम आज भी एक बड़ा सॉफ़्टवेयर रोलआउट तैयार कर रहे हैं, इसलिए मैं कार्यालय नहीं छोड़ सकता। लेकिन थोड़ी देर में मैं ई-मेल का जवाब दे सकता हूं।

मैंने 2 दिन पहले ट्रैविस के लिए OS X बिल्ड जोड़ना शुरू किया है: https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
बिल्ड यहाँ है: https://travis-ci.org/manuelm/libelektra/builds/130898079
यहां चीजें खोलें:

• [ ] cryto_openssl संकलित करने में विफल रहता है
• [] बाइंडिंग परीक्षण विफल
• [] कोई जावा नहीं

मुझे खुशी है अगर कोई यहां से मेरा काम ग्रहण करेगा। मेरे पास OS X नहीं है और OSX सिस्टम का निरीक्षण करने के लिए ट्रैविस की प्रतीक्षा बहुत तेजी से होती है।

पुन: डॉकर: हाँ, ट्रैविस डिफ़ॉल्ट उबंटू संस्करण अच्छी तरह से काम नहीं करता है। यहां तक ​​​​कि सेमेक भी बहुत पुराना है।
अपलोड की गई डॉकटर छवि को लाने में केवल 3 मिनट लगते हैं। और अधिक चित्र जोड़ना कोई ब्रेनर नहीं है। तो मुझे लगता है कि डिफ़ॉल्ट ट्रैविस लिनक्स पर्यावरण में किसी भी नुकसान को हल करने का यह एक अच्छा तरीका है (या अपडेट के बाद हो सकता है)।

मुझे डोकर (बिल्ड + रन) + ट्रैविस (पहले_इंस्टॉल, पहले_स्क्रिप्ट, स्क्रिप्ट) के साथ लिबेलेक्ट्रा (सेमेक + मेक + मेक टेस्ट) के विभिन्न निर्माण और परीक्षण चरणों को एकीकृत करने का एक अच्छा तरीका नहीं मिला है। कमांड पूरा होने के बाद डॉकर कंटेनर बाहर निकल जाते हैं। चूंकि डॉकटर कंटेनर फेंकने के लिए होते हैं, आप बाद में फिर से शुरू नहीं कर सकते। तो आपकी डिस्क/संकलन स्थिति गायब हो जाती है, जब तक कि आप स्थानीय निर्देशिका को कंटेनर में माउंट नहीं करते। अगले सप्ताह डॉकटर पर काम करना जारी रखेगा।

@manuelm बढ़िया, आप आगे बढ़े तो हमने सोचा। पीआर और प्रति प्रतिबद्धता के लिए मैक ओएस एक्स वास्तव में बहुत अच्छा होगा। बहुत सारे लोग अब मैक ओएस एक्स का उपयोग कर रहे हैं और मैं उनके लिए बार-बार निर्माण को तोड़ना नहीं चाहता। आज बैठक में @mpranj ने कहा कि वह आपका काम

नहीं, क्योंकि ट्रैविस फ़ाइल को बाद में अभी भी संशोधित किया जाना है। अन्यथा यह केवल OS X बनाएगा। मैं इसके बजाय पसंद करूंगा यदि @mpranj मेरी ट्रैविस फ़ाइल लेता है और शेष OSX संबंधित मुद्दों को ठीक करता है। फिर मैं उसकी ट्रैविस फ़ाइल ले लूँगा, उसे एक मैट्रिक्स बिल्ड में बदलूँगा और linux/docker बिल्ड + #730 (यदि तब तक उपलब्ध हो) को एकीकृत करूँगा।

पीएस: कृपया उपयोगकर्ता नाम वाले रेपो में ट्रैविस परीक्षण करें। आप बहुत सारे पुश करेंगे :-)

mingw64 पीआर जोड़ा पर बनाता है, काम करना चाहिए। विलंब के लिए क्षमा चाहते हैं। मैं आज ट्रैविस में देखूंगा!

क्या पीआर (जीथब पीआर बिल्डर के साथ) में एक वाक्यांश के साथ बिल्ड जॉब्स को ट्रिगर करने में सक्षम बनाने का एक नकारात्मक पहलू है?

मैं #745 से नौकरियों को कॉन्फ़िगर करना चाहता हूं, इसलिए मैं परीक्षण कर सकता हूं कि मैंने इसे ठीक किया है, लेकिन मैं इसे अधिकांश/(सभी) निर्माण नौकरियों पर लागू कर सकता हूं।

संपादित करें: मैं सभी नौकरियों को स्वचालित रूप से शुरू नहीं करना चाहता, हमारे पास पहले से ही कुछ हैं।

मुझे लगता है कि यह एक अच्छा विचार है यदि हम प्रत्येक कार्य को एक वाक्यांश के साथ ट्रिगर करने के लिए कॉन्फ़िगर कर सकते हैं। मुझे लगता है कि एक छोटा सा नकारात्मक पक्ष है (कम से कम इलेक्ट्रा-टेस्ट-बाइंडिंग के लिए): आपको उस शाखा में प्रवेश करना होगा जिसे आप बनाना चाहते हैं और बस "अभी नौकरी बनाएं" दबा नहीं सकते हैं। यदि आप इसका कोई समाधान ढूंढ़ लें तो बहुत अच्छा होगा।

और आप इसके बारे में सही हैं कि हमें स्वचालित नौकरियों को कम करना चाहिए।

वास्तव में एक बहुत ही सरल उपाय है। हम पीआर बनाने के लिए (env) चर sha1 का उपयोग कर रहे हैं। पैरामीटरयुक्त बिल्ड आपको मूल्य के लिए संकेत देता है, चाहे कोई डिफ़ॉल्ट मान सेट हो या नहीं।

समाधान: env-variable sha1 से master (जेनकींस कॉन्फिग में ही) सेट करें और पैरामीटरयुक्त बिल्ड को अक्षम करें। यदि चर सेट करने में कोई आपत्ति नहीं है, तो यह ठीक वही हल करेगा जो आपने @markus2330 के ऊपर बताया था।

मैंने इसे पहले ही सेट कर दिया है, इसलिए आप उस बिल्ड बटन को हिट कर सकते हैं जैसे elektra-mergerequests और यह मास्टर बनाना शुरू कर देगा।

हाँ, यह एक बहुत अच्छा उपाय है, मुझे यह पसंद है। यह हमें एक स्विच के साथ एक रिलीज शाखा बनाने की अनुमति भी देगा (यदि हमें भविष्य में एक की आवश्यकता है)। तब तक "मास्टर" हमेशा सही विकल्प होता है यदि पीआर के भीतर से निष्पादित नहीं किया जाता है।

मुझे लगता है कि यह फ़िल्टर किए गए पर्यावरण चर की समस्या को भी हल करेगा, जो हमने पहले किया था।

फिर हम बिल्ड-जॉब्स को कम करने के बारे में भी सोच सकते हैं (-मर्जरेक्वेस्ट बुलिड जॉब्स के लिए कोई दोहराव नहीं) और एक नया सुसंगत नामकरण स्कीमा। (सुझाव यहां दिए जा सकते हैं।) एक खुली समस्या हो सकती है: वर्तमान में हम पीआर और मास्टर दोनों के लिए कवरेज, डॉक्यू,... का निर्माण करते हैं और उन्हें अलग-अलग स्थानों पर कॉपी करते हैं। अगर हम बिल्ड जॉब्स को मर्ज करते हैं तो हमें जॉब मास्टर/पीआर-जॉब्स के भीतर अलग-अलग जगहों पर कवरेज, डॉक्यू को कॉपी करने के लिए अंतर करने का एक तरीका चाहिए।

मैंने इसे लगभग सभी नौकरियों में लागू कर दिया है (लेकिन सर्वर _just_ वास्तव में धीमा हो गया है)।
वाइल्डकार्ड बनाने वाली नौकरियों पर लागू नहीं होता ** (डॉक्टर और कुछ अन्य, लेकिन बहुत कम)

यदि आप बाद में (रिलीज समय को छोड़कर) फिर से शुरू करते हैं, तो आप जब भी उस पर काम करना चाहते हैं, तो आप जॉब बनाना बंद कर सकते हैं। आमतौर पर, जेनकिंस ही मशीन की मंदी का कारण है। फिलहाल बैकअप से rsync समस्या हो सकती है, लेकिन यह अत्यावश्यक है।

हाँ, कोई बात नहीं, यह किया जाना चाहिए, लेकिन मैं कुछ अंतिम जाँच करूँगा।

खबर @ElektraInitiative/elektradevelopers:

• जैसा कि उल्लेख किया गया है लगभग _everything_ अब पीआर से और/या केवल बिल्ड बटन दबाकर बनाया जा सकता है
• ट्रिगर वाक्यांश हमेशा elektra- उपसर्ग के बिना नौकरी का नाम होते हैं। (उदाहरण के लिए इलेक्ट्रा-क्लैंग: जेनकिंस बिल्ड क्लैंग प्लीज) मैंने विरासती कारणों से jenkins build please और अन्य पुराने वाक्यांशों को नहीं बदला
• जीथब बिल्ड स्टेटस मैसेज हमेशा बिल्ड जॉब का नाम होता है

धन्यवाद, अच्छा किया! कृपया doc/GIT.md को अपडेट करें ताकि सभी को पता चले कि कौन से वाक्यांश अब काम कर रहे हैं।

(मुझे आशा है कि @mention केवल एक संदेश के लिए काम करता है और हर कोई हमारे द्वारा लिखे गए प्रत्येक संदेश को नहीं पढ़ता है)

एक्सकोड 6.1 बिल्ड के लिए मैक ओएस एक्स टूटा हुआ प्रतीत होता है:
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

मैंने उस के लिए एक पुन: निर्माण शुरू किया लेकिन यह मुझे एक अस्थायी ट्रैविस विफलता की तरह लगता है।

क्या आप दस्तावेज़ बना सकते हैं कि किसी पीआर के लिए किसी बिल्ड को फिर से कैसे ट्रिगर किया जाए? मुझे नहीं पता था कि यह संभव है।

सीधे travis-ci.org पर, ऊपर दिए गए आपके लिंक का उपयोग करते हुए:

मुझे संदेह है कि यह दस्तावेज़-योग्य है लेकिन फिर भी मैं इसे कर सकता हूं।
बिल्ड अभी भी पूरी तरह से गिट चेकआउट के कारण काम नहीं कर रहा है। मुझे नहीं लगता कि यह हमारी गलती है।

आह। मुझे लगता है कि निर्माण शुरू होने/पहले स्थान पर शुरू होने से पहले आपने इसे विलय कर दिया था।
जब मैं अन्य पहले सफल पीआर का पुनर्निर्माण करता हूं, तो यह भी टूट जाता है।

यह किसी भी चीज़ की तुलना में अधिक ट्रैविस समस्या है।

ठीक है, जांच के लिए धन्यवाद।

@ मैनुअल डेबियन-स्थिर-मिमी पहुंच योग्य नहीं है (

Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Removed slice User and Session Slice.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Graphical Interface.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Multi-User System.
etc..

ऐसा लगता है जैसे किसी ने कंटेनर को रोक दिया हो। मैंने इसे फिर से शुरू कर दिया है।

बीटीडब्ल्यू, कल सुबह से मैं अगस्त, 1 तक घर से दूर रहूंगा। मैं अभी भी ई-मेल द्वारा पहुंच योग्य हूं, लेकिन थोड़ी देरी की उम्मीद है।

त्वरित सुधार के लिए धन्यवाद! इसलिए मुझे लगता है कि आप भी अगली बैठकों के लिए यहां नहीं होंगे।

हां

कुछ नौकरियों में त्रुटि है:

Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.

उदाहरण के लिए http://community.markus-raab.org :8080/job/elektra-icheck/lastFailedBuild/console http://community.markus-raab.org :8080/job/elektra-doc/lastFailedBuild/console

यह जेनकींस अपडेट या kdb_import_man शाखा बनाने के कारण हो सकता है?

खुद पर ध्यान दें: cppcms को स्थापित करने की आवश्यकता है।

शाखा के लिए क्षमा करें, मैंने जीथब पेज पर सीधे पीआर को पागल कर दिया।

क्या इस तरह से पीआर बनाना आसान है? क्या जिथब विलय के बाद शाखा को हटाने की पेशकश नहीं करता है?

परिवर्तन इतना कम था, इसलिए मैं आलसी हो गया। बहुत छोटे सुधारों के लिए हाँ, लेकिन स्पष्ट रूप से शाखा बाद में हटाई नहीं जाएगी। मैंने मर्ज के बाद कोई डिलीट ब्रांच नहीं देखी है।

मुझे लगता है कि अस्थिर निर्माण टूटा हुआ है:

Cloning the remote Git repository
Cloning repository git://github.com/ElektraInitiative/libelektra.git
 > git init /home/jenkins/workspace/workspace/elektra-mergerequests-unstable # timeout=10
Fetching upstream changes from git://github.com/ElektraInitiative/libelektra.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: The remote end hung up unexpectedly

पूरा लॉग

@KurtMi अस्थिर काम फिर से (अधिकांश बिल्ड के बीच), लेकिन वॉक त्रुटि कुछ सरल बिल्ड जॉब्स पर बनी रहती है। ऐसा लगता है कि शाखा अभी भी कहीं उपलब्ध है, शायद बिल्ड सर्वर पर कैश में?

 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/* --depth=1
Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.
org.eclipse.jgit.errors.RevWalkException: Walk failure.

@mpranj शायद हमें इन-सोर्स में और स्क्रिप्ट जोड़नी चाहिए, इससे हर बिल्ड जॉब के लिए आसान अपडेट की अनुमति मिलेगी। #806 में हमें बिल्ड डायरेक्टरी में रिक्त स्थान के साथ एक और बग मिला, इसलिए हमें विश्व स्तर पर (हर बिल्ड-जॉब के लिए) बिल्ड डायरेक्टरी में स्पेस जोड़ना चाहिए। मैं पसंद करूंगा यदि हम एक स्क्रिप्ट जोड़ सकते हैं jenkins-setup जो कुछ उपयोगी चर (जैसे export HOME="$WORKSPACE/user space ) को निर्यात करता है और करता है

mkdir "build space"
cd "build space"

इसके अलावा हमें बिल्ड-जॉब्स बनाने चाहिए जो एक वैश्विक रेपो को अपडेट करें। व्यक्तिगत कार्य ऊपर देखें।

वैश्विक रेपो निश्चित रूप से बैंडविड्थ को कम करने में मदद कर सकता है। इन-सोर्स स्क्रिप्ट बनाना भी एक अच्छा विचार हो सकता है, कम से कम उन्हें गिट द्वारा ट्रैक किया जाएगा।

मैं रास्तों में रिक्त स्थान का प्रशंसक नहीं हूं, लेकिन निश्चित रूप से।

पासवार्ड में फास्ट बिल्ड टूटा?

तेजी से निर्माण कार्य कष्टप्रद है, मैं प्रत्येक निर्माण पर kdberrors.h को हटाने का प्रयास करता हूं और देखता हूं कि यह अधिक सुचारू रूप से काम करता है या नहीं। लंबे समय में #730 में @manuelm प्रस्ताव सबसे अच्छा समाधान है: हमें बस यह जांचना चाहिए कि स्रोत कैसे अपडेट हुआ, और इसके आधार पर उचित माप लें।

मुझे लगता है कि #894 फास्ट बिल्ड को भी ठीक करता है, मैं kdberrors.h आउट को हटाने वाली लाइन पर टिप्पणी करूंगा।

कुछ नौकरियां टूट गई हैं, उदाहरण के लिए एचटीएमएल डॉक्टर जॉब।

@mpranj क्या आपके पास इसे देखने का समय है?

@markus2330 हो गया। शेष बिल्ड विफलताएं बिल्ड सिस्टम से संबंधित नहीं लगती हैं।

@mpranj धन्यवाद! आपने इसे ठीक करने के लिए क्या किया? मुझे लगता है कि यह उपयोगी होगा यदि हम यहां सर्वर समस्याओं के निर्माण के समाधान भी एकत्र करते हैं।

मैं "स्रोत कोड प्रबंधन"> "गिट" में बदल गया
"शाखा विनिर्देशक" मान "**" से "${sha1}"

यही हम दूसरे कामों में भी इस्तेमाल करते हैं। यह बिल्ड बाय बटन (शाखा डिफॉल्ट टू मास्टर) या जीथब पीआर बिल्डर (कमिट का sha1) द्वारा ट्रिगर करने की अनुमति देता है।

मुझे एक बार ENV वैरिएबल "sha1" को "मास्टर" पर सेट करना याद है। यह अब गायब लगता है, लेकिन नौकरियां ठीक काम करती हैं तो चलिए इसे अनदेखा करते हैं।

मुझे लगता है कि हम ऑब्जेक्ट लाइब्रेरी का अधिक बार उपयोग करके बिल्ड को और अधिक गति देने में सक्षम होंगे। बहुत सी ऑब्जेक्ट फ़ाइलें कई बार संकलित की जाती हैं। हमें केवल यह सुनिश्चित करना होगा कि हम ऑब्जेक्ट लाइब्रेरी का उपयोग करने वाले प्रत्येक स्थान के लिए संकलन झंडे समान हों, लेकिन मुझे लगता है कि यह आसानी से संभव होना चाहिए।

एक उदाहरण जहां यह एक बड़ा अंतर ला सकता है, मेरी राय में केडीबी है।

@Namoshek कृपया केवल बिल्ड _server_ सामान यहां पोस्ट करें, सामान्य रूप से बिल्ड सिस्टम के बारे में नहीं। ऑब्जेक्ट लाइब्रेरी पहले से ही प्लगइन्स के लिए उपयोग की जाती हैं, लेकिन अलग-अलग वेरिएंट के लिए अलग-अलग ऑब्जेक्ट लाइब्रेरी की आवश्यकता होती है (अलग-अलग कंपाइलर फ़्लैग के कारण)। लेकिन कृपया ठोस सुझावों को अलग मुद्दे के रूप में रिपोर्ट करें (क्या आपका मतलब केडीबी टूल्स है?)

जेनकिंस को 2.7 में अपग्रेड किया गया था, सभी प्लगइन्स अपग्रेड किए गए थे, अनुशंसित प्लगइन्स जोड़े गए थे:

• पाइपलाइन (स्थापना विफल प्रतीत होती है?)
• गिटहब संगठन फ़ोल्डर प्लगइन

और कुछ प्लगइन्स अनइंस्टॉल किए गए:

• शाखा एपीआई
• सीवीएस/एसवीएन (ऐसा लगता है कि अब आवश्यक नहीं है)

इसके अतिरिक्त, प्रत्येक एजेंट पर रूबी-देव स्थापित किया गया था।

मैंने शीर्ष पोस्ट में "वर्तमान मुद्दे" को अपडेट किया। यह महत्वपूर्ण होगा कि इलेक्ट्रा बिना किसी निर्भरता के भी संकलित हो, इसलिए हमें इसे बिल्ड सर्वर एजेंटों के साथ जांचना चाहिए, जिनके पास कोई निर्भरता स्थापित नहीं है (सेमेक और बिल्ड-आवश्यक को छोड़कर)। हालांकि, फ्रीबीएसडी और ओपनबीएसडी बिल्ड एजेंट भी महत्वपूर्ण हैं;)

@mpranj क्या आपको पता है कि elektra-multiconfig-gcc47-cmake-options में क्या गलत है? उनके पास "घातक: संदर्भ एक पेड़ नहीं है:" सभी जगह त्रुटियां हैं। उनकी नौकरी में इसकी कॉन्फ़िगरेशन में "sha1" है?

मैंने मल्टीकॉन्फिग को कंक्रीट कंपाइलर्स से स्वतंत्र बनाया है (विशिष्ट कंपाइलर्स के लिए पर्याप्त अन्य बिल्ड जॉब्स हैं), इसलिए उन्हें किसी भी एजेंट पर चलने में सक्षम होना चाहिए।

@ मार्कस 2330 पता नहीं। मैंने कुछ भी नहीं बदला और बस:

• मास्टर से मैन्युअल रूप से एक निर्माण शुरू किया
• जीथब से एक निर्माण शुरू किया

दोनों निर्माण पेड़ की जांच करने और निर्माण शुरू करने में सक्षम थे।
तो: मैं इसे पुन: पेश नहीं कर सकता।

एक विचार: पीआर होने पर ट्रैविस में समस्या थी और ट्रैविस क्लोन करने से पहले आप इसे मर्ज कर देते हैं। हो सकता है कि कुछ ऐसा ही elektra-multiconfig-gcc47-cmake-options साथ हुआ हो क्योंकि एक निर्माण में ~3hrs लगते हैं।

कलाकृतियों को doc.libelektra.org पर फिर से काम में लाना, जेनकिंस और प्लगइन्स को अपग्रेड किया गया।

मैंने जीथब के वेबहुक में नया बिल्ड सर्वर यूआरएल https://build.libelektra.org अपडेट किया। तो उम्मीद है कि अगले पीआर फिर से बनाए जाएंगे।

जेनकिंस का घर लगभग भर चुका है। यह भी लगता है कि पीआर का निर्माण नहीं किया जा रहा है।

जेनकिंस का घर लगभग भर चुका है।

धन्यवाद मैंने इसका आकार बदल दिया।

यह भी लगता है कि पीआर का निर्माण नहीं किया जा रहा है।

क्या आपको कोई अंदाजा है कि यहां क्या गलत हो सकता है? मैनुअल ट्रिगरिंग काम करता प्रतीत होता है?

doc.libelektra पर दस्तावेज़ प्रकाशित करना। org:12025 बिल्ड के लिए विफल रहा। मैंने एसएसएच सर्वर (बिल्ड-होमपेज एजेंट पर) को पुनरारंभ किया और ऐसा लगता है कि यह फिर से काम करता है।

*.libelektra.org के लिए सर्वर उपलब्ध नहीं है। मैंने हेट्ज़नर में इसकी सूचना दी।

कंटेनर से नेटवर्क कनेक्शन बंद करने का कारण यह था कि libelektra.org से समझौता किया गया था। अधिक जानकारी के लिए #1505 देखें।

यह बहुत अच्छा होगा अगर हम खिंचाव के लिए गिट-बिल्ड-पैकेज जोड़ सकते हैं, वहां अधिक से अधिक जगह आ रही हैं जहां हमें खिंचाव के लिए बनाए गए डेबियन पैकेज की आवश्यकता होगी।

@ बर्नहार्डडेनर क्या आपने शीर्ष पोस्ट को देखा? क्या ऐसा कुछ है जो आप आसानी से कर सकते हैं? क्या भविष्य में बिल्ड सर्वर जॉब में सुधार करते समय @mpranj को कुछ विचार करने की आवश्यकता है?

@sanssecours I (अस्थायी रूप से) के अनुरोध के अनुसार @KurtMi . के लिए जोड़ा

जेनकींस कृपया जीसीसी-कॉन्फ़िगर-डेबियन-ऑप्टिमाइज़ेशन का निर्माण करें

@KurtMi यदि आपको परिवर्तन की आवश्यकता है जो निर्माण कार्य करता है, तो बस स्क्रिप्ट/कॉन्फ़िगर-डेबियन-अनुकूलन संशोधित करें

@sanssecours के पास अब बिल्ड सर्वर तक भी पहुंच है।

बीटीडब्ल्यू। आप नौकरियों को रद्द कर सकते हैं यदि उन्हें किसी भी तरह से अन्य नौकरियों से हटा दिया जाता है (वर्तमान में एक भारी भार है)। केवल ध्यान रखें कि सक्रिय पीआर के लिए नौकरी रद्द न करें, अन्यथा पीआर हरा नहीं होगा। (जब तक आप उन्हें "जेनकींस बिल्ड ... कृपया" वाक्यांश के साथ पुनः आरंभ नहीं करते हैं।)

@sanssecours जेनकिंस को फिर से शुरू किया गया (दूसरी बार)। यदि आप नए प्लगइन्स इंस्टॉल करते हैं तो क्या आप यहां दस्तावेज़ कर सकते हैं। (अपडेट को प्रलेखित करने की आवश्यकता नहीं है)।

पुनरारंभ करने के लिए अनुरोध यहां भी किया जा सकता है।

मैंने कई पीआर को मर्ज करने के लिए अधिक समय देने के लिए "शांत अवधि" को 2 से 5 में बदल दिया और/या दोहराव के पुनर्निर्माण के बिना अलग-अलग कामों को आगे बढ़ाया।

इसके अलावा, मैंने बिल्ड में टाइमआउट का वर्णन करते हुए #1689 मुद्दा खोला (लंबे त्रुटि संदेशों के कारण मैंने इसे यहां नहीं जोड़ा)।

मैंने उपरोक्त कुछ अप्रचलित कार्यों को नए खंड "अप्रचलित/अप्रासंगिक मुद्दे [कारण]:" में भी स्थानांतरित किया।

मैंने बिल्ड सर्वर पर प्लगइन्स को अपडेट किया। उम्मीद है कि अपडेट पीआर #1698 और पीआर #1692 में हमारे पास मौजूद समस्याओं को ठीक कर देंगे।

@markus2330 क्या आप कृपया बिल्ड सर्वर को पुनरारंभ कर सकते हैं?

मैंने जेनकिंस को 2.73.2 से 2.73.3 में अपग्रेड किया और जेनकिंस को फिर से शुरू किया।

उम्मीद है कि अपडेट पीआर #1698 और पीआर #1692 में हमारे पास मौजूद समस्याओं को ठीक कर देंगे।

यह एक सामान्य समस्या हो सकती है जो इन दो पीआर से संबंधित नहीं है? उम्मीद है कि यह अब तय हो गया है।

ऐसा लगता है कि JENKINS_HOME लगभग भर चुका है .

@markus2330 क्या आप कृपया कर सकते हैं

• होम डायरेक्टरी को साफ करें या मुझे बताएं कि मैं यह कैसे कर सकता हूं,
• जेनकींस और सभी पुराने प्लगइन्स को अपडेट करें?

मुझे पिंग करने के लिए धन्यवाद!

ऐसा लगता है कि एक प्लगइन में "मनमाना फ़ाइल पढ़ने की भेद्यता" थी, अर्थात् "स्क्रिप्ट सुरक्षा प्लगइन 1.35"।

मैंने सभी प्लगइन्स को अपग्रेड किया और जेनकिंस को 2.73.3 से 2.89.1 तक अपग्रेड किया।

इसके अलावा, मैंने डिस्क का आकार 20GB से 50GB कर दिया।

हमें जल्द ही सर्वर को पुनरारंभ करना चाहिए, कुछ गैर-पुनरारंभ प्रक्रियाएं हैं जो पुस्तकालय उन्नयन से प्रभावित हो सकती हैं, जो इस समय असुरक्षित हो सकती हैं (हालांकि जेनकींस से संबंधित नहीं)। @ बर्नहार्डडेनर क्या आप पुनरारंभ कर सकते हैं (और अगर कुछ शुरू नहीं होता है तो फिक्स करें)?

कृपया इन अपग्रेड के दौरान मेरे द्वारा तोड़ी गई किसी भी चीज़ की रिपोर्ट करने में संकोच न करें।

सर्वर पर 20 लोड थे और मुश्किल से प्रतिक्रिया दी। हमें "जेनकींस बिल्ड ऑल प्लीज" से सावधान रहने की जरूरत है और लंबी अवधि में हमें एजेंटों को मुख्य सर्वर से दूर ले जाना चाहिए।

मैंने जेनकिंस 2.89.2 में अपग्रेड किया और सर्वर को पुनरारंभ किया। मैं रिपोर्ट करूंगा जब सब कुछ ठीक हो जाएगा और फिर से चल रहा होगा।

ऐसा लगता है कि सभी एजेंट अब त्रुटि से डिस्कनेक्ट हो गए हैं "सर्वर होस्टकी को सत्यापनकर्ता कॉलबैक द्वारा स्वीकार नहीं किया गया था"।

@ बर्नहार्डडेनर मैंने देखा कि कठपुतली आवेदन चल रहा था, क्या आप वर्तमान में सेटअप पर काम कर रहे हैं?

मैंने बिना किसी सफलता के 2.89.1 और 2.73.3 पर डाउनग्रेड करने का प्रयास किया: एजेंटों से कनेक्ट करना अभी भी काम नहीं करता है।

@BernhardDenner को बहुत-बहुत धन्यवाद जिन्होंने ssh समस्या को ठीक किया।

हमें रिलीज नोट्स को पढ़े बिना जेनकिंस को अपग्रेड करना बंद कर देना चाहिए, ऐसा लगता है कि स्थिर अपडेट भी बहुत सी चीजों को तोड़ देते हैं। (जो कि डाउनग्रेड करके भी वापस नहीं किया जा सकता है!)

मुझे बिल्ड सर्वर पर एक बड़ी बाधा की रिपोर्ट करनी है।
elektra-multiconfig-gcc47-cmake-options में 14 घंटे लगते हैं और
elektra-multiconfig-gcc-stable में 4 घंटे लगते हैं।
मुझे यकीन नहीं है कि यह एक नया व्यवहार है और मुझे पता है कि ये नौकरियां एकल निर्माण कार्य नहीं हैं, लेकिन इस बाधा पर ध्यान नहीं दिया जाना चाहिए।

रिपोर्टिंग के लिए धन्यवाद। इन नौकरियों के उप-कार्यों को रेजेन हार्डवेयर में वितरित करने का विचार था, दुर्भाग्य से किसी के पास सेटअप के लिए समय नहीं था। अगर कोई दिलचस्पी रखता है, तो कृपया मुझसे संपर्क करें।

लगता है a7.complang.tuwien.ac.at (ryzen) क्रैश हो गया है। मैंने समस्या की सूचना दी। उम्मीद है कि हमारा एडमिन सोमवार को कंप्यूटर को रीस्टार्ट करेगा।

मैंने अस्थायी रूप से वृद्धिशील (अजीब त्रुटि, # 1784 देखें) को अक्षम कर दिया, व्यवस्थापक ने रेजेन सर्वर को पुनरारंभ किया, और फिर मैंने जेनकींस को पुनरारंभ किया (क्योंकि जेनकींस रेजेन से कनेक्ट नहीं हो सका और रेजेन बिल्ड का एक बड़ा बैकलॉग था)।

ryzen अब फिर से काम करता है और बैकलॉग बनाता है।

इन नौकरियों के उप-कार्यों को रेजेन हार्डवेयर में वितरित करने का विचार था

@markus2330 मैंने देखा है कि Run each configuration sequentially नामक एक विकल्प है। हो सकता है कि यह स्वचालित रूप से वितरित हो जाए यदि हम इसे आसानी से अनचेक करते हैं तो यह एक साथ कई कॉन्फ़िगरेशन विकल्प बनाता है, या आपने इसे पहले से ही आजमाया है?

नहीं, मैंने इसे आजमाया नहीं है, कृपया इसे आजमाएं।

@markus2330 बिल्ड सर्वर कतार से देखते हुए ऐसा लगता है कि यह चाल चल रहा है, मैं इसे जीसीसी-स्थिर-मल्टीकॉन्फिग के लिए काम करने के बाद अतिरिक्त रूप से जीसीसी-स्थिर पर लागू करूंगा

हालांकि मैंने देखा है कि रेजेन उन नौकरियों को संभालने के लिए प्रतीत नहीं होता है। मुझे लगता है कि ऐसा इसलिए है क्योंकि इसे केवल अपने टैग से मेल खाने वाली नौकरियों को संभालने के लिए कॉन्फ़िगर किया गया है और मल्टीकॉन्फिग बिल्ड पहली नज़र में उन टैगों को उचित रूप से सेट नहीं करते हैं। तो हमें या तो ryzen को हर संभव चीज़ पर अमल करना चाहिए या बिल्ड जॉब्स पर अधिक टैग सेट करना चाहिए। ऐसा लगता है कि ryzen उन कार्यों को संभालता नहीं है जिनमें कोई भी टैग सेट नहीं है।

जीसीसी-स्थिर-मल्टीकॉन्फिग के लिए काम करने के बाद मैं इसे जीसीसी-स्थिर पर अतिरिक्त रूप से लागू करूंगा

शुक्रिया!

हालांकि मैंने देखा है कि रेजेन उन नौकरियों को संभालने के लिए प्रतीत नहीं होता है।

नहीं, ऐसा नहीं है, लेकिन यह पहले से ही अन्य नौकरियों का एक समूह निष्पादित करता है। लेकिन शायद हम ऐसा करने के लिए v2 बना सकते हैं?

मैं इसे जीसीसी-स्थिर पर अतिरिक्त रूप से लागू करूंगा

किया हुआ

लेकिन शायद हम ऐसा करने के लिए v2 बना सकते हैं?

मैंने v2 को कॉन्फ़िगर किया है और अब मैं केवल # 1806 पीआर के विलय की प्रतीक्षा करता हूं ताकि मैं इस पर एक से अधिक बिल्ड की अनुमति दे सकूं। मैंने सोचा था कि एसएमटी का उपयोग करने के लिए 8-कोर के साथ -जे 2 के साथ 8 नौकरियां इसके लिए ठीक होनी चाहिए?

बिल्ड-v2 कंटेनर को फिर से शुरू करने के लिए अगर v2 क्रैश हो जाता है या फिर से चालू हो जाता है तो बस टाइप करें। ध्यान दें कि यह केवल तभी किया जा सकता है जब कंटेनर पहले से ही बनाया गया हो - इन निर्देशों के लिए doc/docker/jenkinsnode/README.md का पालन करें। फिर कंटेनर बनने के बाद पुनः आरंभ करने के लिए इस कमांड का उपयोग करें लेकिन रुक गया है:

docker start build-v2

इसके अलावा, नए बिल्ड नोड के ssh कनेक्शन को v2 से a7 के माध्यम से बाहरी दुनिया में अग्रेषित करने के लिए, मैंने a7 पर निम्नलिखित ssh सुरंग स्थापित की है (डॉकर कंटेनर v2 पर अपने ssh पोर्ट को 22222 पर मैप करता है):

ssh -L 0.0.0.0:22222:localhost:22222 <username>@v2.complang.tuwien.ac.at

इसके अलावा, डॉक कंटेनर की सार्वजनिक ssh कुंजी हर छवि के पुनर्निर्माण पर बदल जाती है और इस प्रकार इसे बिल्ड सर्वर में भी समायोजित करना पड़ता है। यह आवश्यक नहीं है यदि कंटेनर केवल पुनरारंभ होता है। इसका पता लगाने के लिए, v2 पर निम्नलिखित दर्ज करें:

sudo docker exec -it build-v2 bash
# now you should be on the docker machine
cat /etc/ssh/ssh_host_ecdsa_key.pub
> ecdsa-sha2-nistp256 <blablablalb> <root@6b906cc01f23>

केवल पहली दो चीजों को कॉपी करें, इसलिए कुंजी एल्गोरिदम और कुंजी ही, इस उपयोगकर्ता जानकारी को ssh कुंजी के लिए जेनकींस में ryzen-v2 के कॉन्फ़िगरेशन के अंत में कॉपी न करें!

v2 बंद है, मैंने व्यवस्थापक को सूचित किया। यह काफी अजीब है: a7 और v2 दोनों पूरी तरह से नए हार्डवेयर हैं और घटनाएं काफी बार होती हैं।

v2 वापस आ गया है और मैंने वहां बिल्ड कंटेनर को पुनरारंभ कर दिया है। इसलिए उम्मीद है कि अब हमारे पास फिर से तेजी से निर्माण होगा। इसके अतिरिक्त मैंने इलेक्ट्रा-हास्केल को "जेनकींस बिल्ड ऑल प्लीज" में जोड़ा है क्योंकि मैं अपने टाइपचेकर के लिए स्थिर हैकेल बनाना चाहता हूं, इसलिए परीक्षण एक अच्छा जोड़ है।

इसके अलावा मैं यहां एक नोट छोड़ना चाहता हूं कि हम अतिरिक्त रूप से एक और बिल्ड नोड बनाना चाहते हैं जो एमएम बिल्ड की देखभाल करता है जो अब v2 पर भी नई बाधा प्रतीत होता है।

अंत में, @markus2330 मुझे लगता है कि पॉइंट रन बैशिज्म चेकर पहले ही किया जा चुका है, क्योंकि यह हमारे सामान्य परीक्षणों में से एक है /testscr_check_bashisms.sh ।

debian-jessie-homepage||homepage लेबल के सभी नोड और बिल्ड एजेंट debian-wheezy-mr वर्तमान में ऑफ़लाइन हैं। बिल्ड एजेंट को पुनरारंभ करना काम नहीं करता। यह वास्तव में अच्छा होगा यदि एसएसएच या इन नोड्स तक भौतिक पहुंच वाला कोई व्यक्ति इस समस्या को देख सके।

मैंने vservers को पुनरारंभ किया लेकिन जेनकींस के भीतर एजेंटों को पुनरारंभ करने से त्रुटि के साथ काम नहीं किया "अनुरोध में कोई वैध टुकड़ा शामिल नहीं था"। @ बर्नहार्डडेनर क्या आपके पास कोई विचार है?

ऐसा लगता है कि v2 भी नीचे है। तो हमारे पास 3 गैर-कार्यात्मक एजेंट हैं 😢

v2 वापस आ गया है, लेकिन मुझे आश्चर्य है कि यह हमेशा नीचे क्यों जाता है? क्या यह हमारी निर्माण प्रक्रिया से संबंधित हो सकता है?

"कोई वैध टुकड़ा नहीं" के बारे में मैंने वह भी देखा जब मैंने एजेंट को v2 पर पुनरारंभ करने का प्रयास किया, लेकिन जब मैंने इसे फिर से कोशिश की तो यह काम किया।

v2 वापस आ गया है, लेकिन मुझे आश्चर्य है कि यह हमेशा नीचे क्यों जाता है? क्या यह हमारी निर्माण प्रक्रिया से संबंधित हो सकता है?

यह एक कर्नेल/हार्डवेयर विफलता प्रतीत होता है (जब कंप्यूटर हैंग हो जाता है तो sysreq भी काम नहीं करता है)। हमारा उपयोग त्रुटि को ट्रिगर कर सकता है। कंप्यूटर कई महीनों से बिना किसी त्रुटि के चल रहा था और जब से हम इसका उपयोग करते हैं हम इसे पहले ही तीन बार क्रैश कर चुके हैं।

मैंने कर्नेल को अपग्रेड किया और एक्स-सर्वर को शुद्ध किया।

"कोई वैध टुकड़ा नहीं" के बारे में मैंने वह भी देखा जब मैंने एजेंट को v2 पर पुनरारंभ करने का प्रयास किया, लेकिन जब मैंने इसे फिर से कोशिश की तो यह काम किया।

शुक्रिया! मैं अब होमपेज एजेंट को फिर से शुरू करने में सक्षम था।

इसके अलावा, मैंने एजेंट डेबियन-जेसी-मिनिमल और उसके निर्माण कार्य को अक्षम कर दिया। हमें न्यूनतम नौकरियों के लिए डॉकटर कंटेनर बनाने चाहिए, मैंने इसे कार्य के रूप में जोड़ा।

जैसा कि हम कल आश्चर्यचकित थे क्योंकि सामुदायिक सर्वर नीचे था क्योंकि यह दुर्घटनाग्रस्त हो गया था और एक गलत एआरपी-कैश ने हमारे आईपी को अन्य सर्वरों पर पुनर्निर्देशित कर दिया था। पुनः आरंभ करने के बाद, सब कुछ फिर से काम कर गया, लेकिन रेड सिंक अभी भी जारी है। (अधिक भार के कारण यह इतना धीमा हो सकता है।)

कम्युनिटी सर्वर का लोड लगभग 10 है। फिलहाल यह 13.20 11.29 9.35 है। हमें वास्तव में सामुदायिक सर्वर पर सीधे चलने वाली नौकरियों को कम करना चाहिए और लोड को v1. कोई स्वयमसेवक?

जेनकिंस का 2.89.2 से 2.89.4 तक अपग्रेड है। दुर्भाग्य से मुझे चैंज को देखने का कोई आसान तरीका नहीं मिला ( apt-get changelog विफल रहता है क्योंकि यह एक अनौपचारिक पैकेज है)। इस अद्यतन को न करने का कोई कारण?

अपस्ट्रीम चैंज https://jenkins.io/changelog-stable/ पर है
जाहिरा तौर पर 2.89.4 में सुरक्षा सुधार शामिल हैं।

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

मैंने जेनकिंस 2.89.4 में अपग्रेड किया और सब कुछ फिर से चल रहा है।

इलेक्ट्राहोमपेज रिबूट के बाद डिफ़ॉल्ट रूप से शुरू नहीं हुआ था, मैंने उसे बदल दिया (/etc/vservers/elektrahomepage/apps/init/mark=default)।

मैंने टेस्ट-डॉकर बिल्ड जॉब को भी सक्रिय किया।

v2 नीचे है, फिर से: रोओ:

लेकिन अब कम से कम a7 स्थिर होता दिख रहा है।

मैंने a7 और स्ट्रेच नोड (डेबियन-स्ट्रेच-एमआर) पर क्लैंग-फॉर्मेट-5.0 स्थापित किया।

अगले पीआर के लिए कृपया क्लैंग-प्रारूप-5.0 के अनुसार सुधार करें।

https://build.libelektra.org/jenkins/job/elektra-clang-asan/ अस्थायी रूप से अक्षम कर दिया गया था।

हम वर्तमान में v2 की जांच कर रहे हैं। यूईएफआई 6.6.17 से है। ऐसा लगता है कि दुर्घटनाएं हमेशा सप्ताहांत में होती हैं, शायद उस समय अधिक भार होता है? मैं v2 पर v1 सेटअप को दोहराने की कोशिश करूंगा।

v1 और v2 एक ही कर्नेल के साथ ऊपर और चल रहे हैं।

@ e1528532 ऐसा लगता है कि आपका ssh ब्रिज शुरू नहीं हुआ और doc/docker/jenkinsnode/README.md में कमांड "संदर्भ तैयार करने में असमर्थ: Dockerfile पथ में सिम्लिंक का मूल्यांकन करने में असमर्थ: lstat /root/Dockerfile: ऐसी कोई फ़ाइल या निर्देशिका नहीं है। "और फिर" छवि 'बिल्डेलेक्ट्रा- स्ट्रेच: नवीनतम ' स्थानीय रूप से खोजने में असमर्थ"। इसका मतलब है कि v2 इस समय उपलब्ध नहीं है।

@markus2330 ने लिखा: मुद्दे को #1829 पर ले जाया गया

मुझे लगता है कि बिल्ड सर्वर के नवीनतम अपडेट में से एक ने तोड़ दिया elektra-gcc-configure-debian-stretch , जो अब रिपॉजिटरी से कनेक्ट करने में

stderr: fatal: Unable to look up github.com (port 9418) (Name or service not known)

.

मुझे लगता है कि समस्या elektra-gcc-configure-debian-stretch के साथ बिल्ड सर्वर ryzen , जो गिटहब से कनेक्ट करने में असमर्थ है। मैंने निर्माण कार्य के लिए लेबल को तदनुसार debian से debian-stretch-mr । अब बिल्ड जॉब फिर से काम करने लगता है ।

ryzen, जो GitHub से कनेक्ट करने में असमर्थ है

ऐसा लगता है कि हमारे व्यवस्थापक के NetworkManager ने "manged=true" के साथ फिक्स विश्वसनीय काम नहीं किया। पुनरारंभ करने के बाद "/etc/resolv.conf" फिर से एक झूलता हुआ सिम्लिंक था। मैंने इसे फिर से ठीक किया, गिटहब को रेजेन से पहुंचा जा सकता है। rzyen v2 दुर्भाग्य से अभी भी उपलब्ध नहीं है (ssh ब्रिज गायब है)।

इलेक्ट्रा 0.8.22 अंत में जारी किया गया है। वेबसाइट बनने के बाद मैं #676 में लिंक जोड़ूंगा, वेबसाइट बनाने में एक घंटे से अधिक समय लगता है। हो सकता है कि हम होमपेज बिल्ड को एक तेज मशीन पर ले जा सकें और परिणामी वेबसाइट को उसके स्थान पर ही कॉपी कर सकें।

मुझे लगता है कि हमने उस सर्वर के बारे में कुछ किया है जो http://build.libelektra.org को होस्ट करता है मिनट लगते हैं, अगर हम सर्वर से कनेक्ट करने में सक्षम हैं:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request <em><a href="/jenkins/">GET&nbsp;/jenkins/</a></em>.<p>
Reason: <strong>Error reading from remote server</strong></p></p>
<hr>
<address>Apache/2.4.10 (Debian) Server at build.libelektra.org Port 443</address>
</body></html>

.

हां, न केवल जेनकींस बल्कि इस सर्वर पर चलने वाली हर चीज प्रभावित है। मेरे लिए अक्सर स्थिति भी अस्वीकार्य होती है। ऐसा लगता है कि रैम बहुत कम है। (2GiG स्वैप का उपयोग किया जाता है)

जेनकिंस इसका कारण हो सकता है, दर्जनों जावा प्रक्रियाएं हैं जो सूची को htop में ले जाती हैं। लंबे समय तक हमारे पास पर्याप्त रैम थी और स्वैप का शायद ही उपयोग किया जाता था, और हमने ज्यादा बदलाव नहीं किया (जेनकिंस को अपग्रेड करने और बिल्ड जॉब्स की संख्या बढ़ाने के अलावा)।

मेरा सुझाव है कि कम्युनिटी सर्वर को एजेंट के रूप में इस्तेमाल करना बिल्कुल भी बंद कर दें। इसके लिए हमें v2 बैक की आवश्यकता होगी लेकिन @e1528532 व्यस्त प्रतीत होता है। हम एक बेहतर सर्वर भी किराए पर ले सकते थे लेकिन फिर हमें किसी ऐसे व्यक्ति की आवश्यकता होगी जिसके पास प्रवासन के लिए समय हो।

@markus2330 क्या आप कृपया बिल्ड सर्वर को पुनरारंभ कर सकते हैं? वर्तमान में elektra-todo जैसे साधारण कार्य भी विफल हो जाते हैं।

मैंने रविवार को v2 को फिर से शुरू किया लेकिन जाहिर तौर पर यह पहले से ही फिर से नीचे है, इसलिए हमें इस पर अन्य चीजों को रखने के बारे में सोचने से पहले पहले v2 को स्थिर करना चाहिए।

मैंने जेनकींस को पुनरारंभ किया और v2. लगता है जेनकिंस फिर से सुचारू रूप से चल रहा है।

@ e1528532 एसएसएच सुरंग अभी भी काम नहीं कर रही है। a7 को पुनरारंभ करने के बाद भी v2 से कनेक्ट करना संभव नहीं है।

इसलिए अन्य चीजों को रखने के बारे में सोचने से पहले हमें पहले v2 को स्थिर करना चाहिए।

मुख्य डाउनटाइम ssh ब्रिज के कारण हुआ। यदि v2 में परेशानी होती है तो इसे आमतौर पर एक दिन के भीतर पुनः आरंभ किया जाता है।
मैंने अब शेष एक्स सर्वर को हटा दिया है, इसलिए मुझे आशा है कि v2 अब भी स्थिर है। ए 7 के लिए यह चाल लग रहा था (काफी समय के लिए कोई पुनरारंभ आवश्यक नहीं था)। v2 पर लोड के बिना (जिसके लिए ssh ब्रिज की आवश्यकता होती है), हालांकि, हम निश्चित रूप से यह नहीं जान पाएंगे कि यह स्थिर है या नहीं।

हार्डवेयर (पुनरारंभ) और सॉफ़्टवेयर (जेनकिंस अपग्रेड) के बारे में चर्चा को विभाजित करने के बारे में क्या?

ऐसा लगता है कि a7 और v2 के बीच नेटवर्क कनेक्टिविटी समस्या है। v2 चालू है और चल रहा है लेकिन फिर भी मुझे "होस्ट करने का कोई मार्ग नहीं" मिलता है। ऐसा लगता है कि मैं इसे आज ठीक नहीं कर सकता।

v2 का नेटवर्क डाउन था क्योंकि GNOME के ​​​​डिइंस्टॉलेशन ने नेटवर्क-मैनेजर को भी हटा दिया था। अब हमने नेटवर्क (/etc/नेटवर्क/इंटरफेस का उपयोग करके) को ठीक किया और नवीनतम BIOS/UEFI में अपग्रेड किया। इसलिए उम्मीद है कि अब सब कुछ स्थिर है।

बीटीडब्ल्यू। एक और हार्डवेयर है जिसे हम ssh ब्रिज के माध्यम से उपयोग कर सकते हैं ... (PCS)

ऐसा लगता है कि एसएसएच सुरंग अभी भी काम नहीं कर रही है। a7 को पुनरारंभ करने के बाद भी v2 से कनेक्ट करना संभव नहीं है।

हाँ यह स्वचालित नहीं था। अब मैंने सब कुछ संभाल लिया है। यदि मशीन फिर से चालू होती है तो डॉकटर कंटेनर को अब स्वचालित रूप से पुनरारंभ करना चाहिए। कम से कम मैंने https://stackoverflow.com/questions/29603504/how-to-restart-an- मौजूदा-docker-container-in-restart-always-mode के अनुसार --restart ध्वज को "हमेशा" पर सेट किया है

इसके अलावा मैंने "ssh-tunnel-a7-v2" नामक एक नया उपयोगकर्ता बनाया है जिसमें a7 और v2 दोनों पर कोई पासवर्ड सेट नहीं है (इसलिए, उस के लिए अक्षम पासवर्ड प्रमाणीकरण)। मैंने a7 पर उपयोगकर्ता के लिए एक ssh प्रमाणपत्र बनाया और इसकी सार्वजनिक कुंजी को v2 पर ज्ञात होस्ट में जोड़ा। फिर मैंने /etc/systemd/system/ssh-tunnel-a7-v2.service में एक सिस्टमड सेवा जोड़ी, जो https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service के अनुसार सिस्टमड सेवा के रूप में स्वचालित रूप से ssh टनल को खोलती है। इसलिए यह तब भी काम करना चाहिए जब सर्वर फिर से चालू हो जाए या ssh कनेक्शन क्रैश हो जाए और अब मुझ पर या मेरे उपयोगकर्ता पर निर्भर न हो। प्रमाणपत्र के उपयोग के कारण कनेक्शन के लिए किसी पासवर्ड का उपयोग करने की आवश्यकता नहीं है।

उसके शीर्ष पर, इस नए स्वचालित कॉन्फ़िगरेशन के सक्रिय होने के साथ निश्चित रूप से v2 को पुनरारंभ किया गया है। उम्मीद है कि यह अगली दुर्घटना से बच जाएगा (यदि कोई है तो), सैद्धांतिक रूप से यह होना चाहिए लेकिन हम देखेंगे।

निर्माण कार्य test-docker हमेशा विफल रहता है, यदि जेनकींस ryzen v2 पर कार्य निष्पादित करता है:

docker inspect -f . elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: docker: not found
[Pipeline] sh
[test-docker] Running shell script
+ docker pull elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: docker: not found

. मैं नौकरी को ryzen v2 अलावा अन्य नोड्स तक सीमित करना चाहता था, लेकिन ऐसा लगता है कि इस चरण का विकल्प test-docker के

इसमें देखने के लिए धन्यवाद! क्या एजेंटों को एकाधिक लेबल असाइन करना संभव नहीं है? तब आप ryzen v2 को एक अद्वितीय लेबल असाइन कर सकते हैं और उस पर कार्य को जोड़ सकते हैं।

सौभाग्य से, हमें जल्द ही हमारे बिल्ड सर्वर के लिए समर्थन मिलेगा: +1:

क्या एजेंटों को एकाधिक लेबल असाइन करना संभव नहीं है?

जहाँ तक मैं हाँ जानता हूँ, एक एजेंट को एकाधिक लेबल असाइन करना संभव है।

तब आप ryzen v2 को एक अद्वितीय लेबल असाइन कर सकते हैं और उस पर कार्य को जोड़ सकते हैं।

जैसा कि मैंने पहले ही कहा था [[1]] विकल्प "जहां इस परियोजना को चलाया जा सकता है प्रतिबंधित करें" गायब प्रतीत होता है:

मैं नौकरी को ryzen v2 अलावा अन्य नोड्स तक सीमित करना चाहता था, लेकिन ऐसा लगता है कि इस चरण का विकल्प test-docker के

.

आह, मैंने आपके कथन को गलत समझा: "बूलियन अभिव्यक्ति लिखने का कोई तरीका नहीं है जो मुझे (स्थिर &&! ryzenv2) कहने की अनुमति देता है", ऐसा नहीं है कि एजेंट प्रतिबंध के लिए कोई विकल्प नहीं है।

शायद यह डीएसएल द्वारा किया जा सकता है। मैं लुकास से पूछूंगा कि क्या वह जानता है कि क्या करना है।

नमस्ते,

जैसा कि @sanssecours ने नोट किया है कि ryzen v2 में docker इंस्टॉल नहीं है, लेकिन इसमें docker टैग है।
टेस्ट-डॉकर रन के लिए डॉक टैग रखने के लिए नोड्स की आवश्यकता होती है।

संभावित समाधान या तो नोड पर डॉकटर स्थापित करना है या जेनकिंस में नोड से टैग को हटाना है

संभावित समाधान या तो नोड पर डॉकटर स्थापित करना है या जेनकिंस में नोड से टैग को हटाना है

समस्या का समाधान प्रदान करने के लिए धन्यवाद। मैंने अभी-अभी docker टैग को ryzen v2 से हटा दिया है। जहाँ तक मैं बता सकता हूँ अब सब कुछ काम करने लगता है।

मैंने यह दर्शाने के लिए 'ryzen v2' नोड के विवरण को अपडेट किया है कि यह वास्तव में 'केवल' एक docker कंटेनर है जो v2 पर चल रहा है। इसलिए डॉकर उपलब्ध नहीं था, भले ही यह v2.

जेनकींस में एक प्लगइन भी जोड़ा जो आसान निर्माण डेटा विज़ुअलाइज़ेशन की अनुमति देता है (प्रत्येक बिल्ड में क्लिक करने की आवश्यकता नहीं है)

v2 फिर से नीचे है, मैंने इसकी सूचना दी।

मैंने v2 को रीबूट किया लेकिन एजेंट को फिर से कनेक्ट नहीं कर सका।

कम से कम हमें अंत में दुर्घटना से पहले जो हुआ उसके त्रुटि संदेश मिले (निश्चित रूप से इस बात की कोई गारंटी नहीं है कि त्रुटि संदेशों का दुर्घटना से कोई लेना-देना नहीं है):

watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [docker-containe:789]
...
NMI watchdog: Watchdog detected hard LOCKUP on cpu 14
...

अजीब, ऐसा लगता है कि मेरी पुनरारंभ मशीनरी ने काम किया, दोनों ssh सुरंग और डॉकटर नोड्स को पुनरारंभ किया गया था और मैं a7.complang.tuwien.ac.at -p 22222 से जुड़ सकता हूं, जिसका अर्थ है कि सब कुछ खुला होना चाहिए। हालांकि किसी भी तरह जेनकींस मुझे किसी कारण से एक अनंत चरखा दिखाते हैं, कोई टाइमआउट नहीं, कुछ भी नहीं।

मैंने अपने मैनुअल एसएसएच ब्रिज की कोशिश की जैसे हमने पहले किया था, वही। डॉकटर कंटेनर को एक बार फिर से शुरू किया, वही। तो ईमानदारी से मुझे यकीन नहीं है कि त्रुटि संदेश के बिना अब वास्तव में क्या गलत है, केवल एक चीज जो मुझे मिली वह कुछ ऐसा व्यक्ति है जिसके पास स्पष्ट रूप से एक समान बग है (कताई पहिया लेकिन कोई संदेश नहीं) लेकिन पूरे मास्टर जेनकींस को पुनरारंभ करने के अलावा उस पर कोई समाधान नहीं है नोड (जो मैंने कोशिश नहीं की है): https://issues.jenkins-ci.org/browse/JENKINS-19465

संपादित करें: मैंने सुझाए गए वर्कअराउंड में से एक की कोशिश की (होस्टनाम कॉन्फ़िगरेशन को किसी ऐसी चीज़ पर रीसेट करें जो मौजूद नहीं है, फिर से कनेक्ट करें, फिर जेनकिंस को पता चलता है कि होस्टनाम गलत है, वास्तविक होस्टनाम में वापस बदलें, फिर यह बिना किसी और परेशानी के अचानक काम करता है)। तो मुझे लगता है कि यह त्रुटि मेरे पुनरारंभ सेटअप के साथ कुछ के बजाय हुई, लेकिन अगले दुर्घटना के लिए उस पर सुनिश्चित होने की प्रतीक्षा करें;)

@markus2330 मुझे यकीन है कि आप पहले ही इसे स्वयं ढूंढ चुके हैं लेकिन एक त्वरित खोज ने मुझे दिखाया कि यह सी-स्टेट कॉन्फ़िगरेशन से संबंधित हो सकता है: https://bugzilla.kernel.org/show_bug.cgi?id=196683 , कुछ सुझाव दिए गए हैं उसके लिए उपाय

ऐसा लगता है कि बिल्ड सर्वर ryzen हमारे भंडार से कनेक्ट करने में

https://github.com/ElektraInitiative/libelektra.git . से लाने में विफल

.

डीएनएस कॉन्फिग फिर से लटक रहा था। चूंकि मैं पूरी तरह से समझ नहीं पा रहा हूं कि ऐसा क्यों है
जिस तरह से यह वर्तमान में सेटअप है, मैंने केवल नेमसर्वर सेटिंग्स को पुनर्स्थापित किया है और
डॉकर बिल्ड जॉब को फिर से शुरू किया।

12 मार्च 2018 को 17:03 बजे, रेने श्वाइगर नोटिफिकेशन @github.com ने लिखा:

ऐसा लगता है कि बिल्ड सर्वर ryzen हमारे भंडार से कनेक्ट करने में असमर्थ है
https://build.libelektra.org/jenkins/job/test-docker/162/console :

https://github.com/ElektraInitiative/libelektra.git . से लाने में विफल

.

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-372363457 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEOv-gcB-XWqDbqbRZfRnfnadYjZN21hks5tdpxLgaJpZM4DIApm
.

चूँकि मैं पूरी तरह से समझ नहीं पा रहा हूँ कि इसे वर्तमान में जिस तरह से सेटअप किया गया है, उसे क्यों सेट किया गया है

मुझे डर है कि कोई इसे न समझे। हो सकता है कि DNS सर्वर गलत तरीके से कॉन्फ़िगर किया गया हो और उचित नेमसर्वर जानकारी नहीं देता हो। v2 के लिए हमने नेटवर्क मैनेजर को अनइंस्टॉल कर दिया है और ऐसा लगता है कि resolv.conf अब वहां स्थिर है। तो एक विकल्प नेटवर्क मैनेजर को a7 पर भी अनइंस्टॉल करना है। (और /etc/network/interfaces का उपयोग करें) कोई कारण नहीं है कि v2 और a7 में अलग-अलग सेटअप हैं, यह केवल मैला प्रशासन के कारण है।

आदर्श रूप से (लंबे समय में), हम कठपुतली का उपयोग करके दोनों का प्रबंधन करते हैं।

https://bugzilla.kernel.org/show_bug.cgi?id=196683 , इसके लिए कुछ सुझाव दिए गए हैं

C6 को अक्षम किया जाना चाहिए लेकिन हम जांच जारी रखेंगे।

ऐसा लगता है कि नए बिल्ड एजेंट "राइजेन वी2 डॉकर" में "डेबियन-स्टेबल-एमएम" की तरह चलने वाला डी-बस डेमॉन नहीं है।

क्या कोई कृपया इसे स्थापित/शुरू कर सकता है या मुझे बता सकता है कि कौन सी स्क्रिप्ट multiconfig-gcc47-cmake-options बिल्ड को कॉन्फ़िगर करती है ताकि मैं यह सुनिश्चित करने के लिए एक स्निपेट जोड़ सकूं कि यह शुरू हो गया है?

@ मार्कस 2330 मुझे संदेह है क्योंकि दोनों ifupdown और networkmanager सक्षम हैं, वे दोनों एक दूसरे के बालों में समा जाते हैं। दोनों में से किसी एक को अक्षम करने से निश्चित रूप से मदद मिलेगी।

ठीक है, मैंने v2 के अनुरूप होने के लिए a7 पर gnome और network-manager को हटा दिया।

ऐसा लगता है कि नए बिल्ड एजेंट "राइजेन वी2 डॉकर" में "डेबियन-स्थिर-मिमी" की तरह चलने वाला डी-बस डेमॉन नहीं है।

बिल्ड एजेंट एक डॉकटर कंटेनर के भीतर रहता है, उम्मीद है कि @ e1528532 आपको वहां dbus डेमॉन शुरू करने में मदद कर सकता है।

धन्यवाद। यह काफी आसान होना चाहिए। मैं इसे निम्नलिखित कमांड के साथ डॉकटर कंटेनर (उबंटू 17.10 से निर्मित docs/docker/Dockerfile ) में शुरू करता हूं:

mkdir /var/run/dbus # create directory for pidfiles & co
dbus-daemon --system

बिल्ड सर्वर ryzen हमारे रिपॉजिटरी से फिर असमर्थ है ।

माफ़ कीजियेगा, मेरी गलती। ऐसा लगता है कि नेटवर्क-मैनेजर को रोकना सिस्टम को तोड़ने के लिए काफी था।

इसे अब ठीक किया जाना चाहिए। कृपया किसी और समस्या की रिपोर्ट करने में संकोच न करें।

@ मार्कस 2330 पूरा यकीन है कि यह अगले रिबूट पर फिर से टूट जाएगा

मैंने /etc/network/interfaces फ़ाइल को फिर से करने की स्वतंत्रता ली (और इंटरफेस के कॉन्फ़िगरेशन को /etc/network/interfaces.d में स्थानांतरित कर दिया)
नेटवर्क प्रबंधक की स्थापना रद्द करने के साथ संयुक्त रूप से इसे स्थिर रखना चाहिए

कृपया कॉन्फ़िगरेशन की समीक्षा करें और यह देखने के लिए कि क्या यह काम करता है, रिबूट को ट्रिगर कर सकता है

@ingwinlu ठीक करने के लिए धन्यवाद, रिबूट ने अच्छी तरह से काम किया।

मुझे पता चला कि मैंने बहुत सारे पैकेज हटा दिए हैं, इसलिए मैंने जावा (ओपनजेडके 9 हेडलेस और डिफॉल्ट-जेआर) को फिर से स्थापित किया: मुस्कान:

@ingwinlu क्या आप कृपया v2 एजेंट पर dbus चला सकते हैं? आदर्श रूप से कृपया "/home/armin/buildelektra-stretch/Dockerfile" को कुछ गैर-उपयोगकर्ता विशिष्ट गंतव्य पर भी स्थानांतरित करें।

@ मार्कस 2330 बिल्ड वातावरण के साथ आगे बढ़ने के लिए मेरा प्रस्ताव वास्तव में वर्तमान डॉकटरकंटेनर-ऑन-वी2 नोड को हटाने और इसे एक सक्षम डॉकटर के साथ बदलने की भविष्यवाणी करता है (यानी अब v2 पर डॉकटर कंटेनर की ओर इशारा नहीं करता है, लेकिन सीधे v2 को इंगित करता है) .

बाद में हम परीक्षण के लिए आवश्यक विभिन्न वातावरण प्रदान करने के लिए रिपॉजिटरी में चेक किए गए Dockerfiles से छवि बनाने के लिए बिल्ड पाइपलाइन को सेटअप कर सकते हैं।

जब मैं इसे प्राप्त करता हूं तो मैं एक dbus सक्षम डॉकटर छवि के रोल आउट को प्राथमिकता दे सकता हूं, लेकिन मैं ऐसा काम नहीं करना चाहूंगा जो जल्द ही अप्रासंगिक हो जाए अगर मुझे ऐसा करने की आवश्यकता नहीं है।

हाँ, यह समझ में आता है!

v2 का दीर्घकालिक लक्ष्य यह है कि हमें इसे कुछ अन्य डॉकटर कंटेनरों (इलेक्ट्रा के लिए नहीं) के साथ साझा करना होगा, इसलिए यह एक अच्छी बात होगी यदि हमारे सभी भागों को इस तरह से वर्चुअलाइज किया जाए कि वे अन्य डॉकटर कंटेनरों को प्रभावित न कर सकें। (शायद रिकर्सिव डॉकर या ज़ेन?) हम समान सेटअप के लिए a7 के लिए ऐसा ही कर सकते हैं/कर सकते हैं।

हम मशीनों पर सीधे पहुंच जारी रखेंगे लेकिन हमें किसी भी जोखिम को कम करना चाहिए जो जेनकिंस डॉकर मशीनों को मार सकता है जिसका इससे कोई लेना-देना नहीं है।

कुछ एजेंटों के लिए हमारे पास पहले से ही कठपुतली सेटअप है। यह बहुत अच्छा होगा यदि हम इसे बायपास न करें या इससे भी बेहतर: इस सेटअप को a7 और v2 के लिए बढ़ाएँ। मुझे उम्मीद है कि @BernhardDenner जल्द ही आपको इसके बारे में और जानकारी दे सकता है।

बिल्ड सर्वर फिर से डाउन हो गया है।

वैसे, हम बिल्ड सर्वर स्थिति के बारे में चर्चा को गिटहब टीम चर्चा में ले जा सकते हैं, क्योंकि यह विषय इस मुद्दे की सदस्यता लेने वाले सभी लोगों के लिए दिलचस्प नहीं हो सकता है।

हां, बिल्ड सर्वर सहित पूरा सर्वर डाउन है: क्राई: और v2 भी डाउन है (स्वतंत्र रूप से)। मैंने v2 को पुनरारंभ किया और UEFI में C-States विकल्प को बदल दिया। लेकिन ऐसा लगता है कि हमारे सर्वर में कोई बड़ी समस्या है। उम्मीद है कि हम इसे अधिक मेमोरी के साथ बेहतर हार्डवेयर से बदल देंगे: crossed_fingers:

गिटहब टीम चर्चा

यदि हम GitHub टीम चर्चा में कुछ लिखते हैं, तो क्या ElektraDevelopers के सभी लोगों को सूचित नहीं किया जाता है? यहां इस अंक में हर कोई यह तय कर सकता है कि वह सदस्यता लेना चाहता है या नहीं।

मेरे लिए अभी भी एक खुला प्रश्न यह है कि क्या हमें इस मुद्दे को दो मुद्दों में विभाजित करना चाहिए: हार्डवेयर से संबंधित और जेनकिंस से संबंधित।

यदि हम GitHub टीम चर्चा में कुछ लिखते हैं, तो क्या ElektraDevelopers के सभी लोगों को सूचित नहीं किया जाता है?

जहाँ तक मैं बता सकता हूँ, हाँ।

यहां इस अंक में हर कोई यह तय कर सकता है कि वह सदस्यता लेना चाहता है या नहीं।

टीम डिस्कशन के लिए भी यही

बिल्ड सर्वर फिर से चालू है। सेटिंग्स बदली गईं:

• xms और xmx सेटिंग्स जब कतार में बहुत सारे निर्माण होते हैं तो कचरा संग्रहण की मात्रा को कम करने के लिए
• मैंने देखा कि हम scm मतदान का उपयोग करते हैं। मैंने एक समय में वैश्विक स्तर पर 4 समवर्ती चुनावों के लिए पोलर को थ्रॉटल किया ताकि सर्वर को वर्तमान में मिलने वाले स्पाइक्स को थोड़ा कम किया जा सके।

संपादित करें:

* सभी पाइपलाइनों के लिए # बिल्ड को 30 पर रखने के लिए सेट करें क्योंकि कई स्रोतों के अनुसार वे वेबुई तक पहुँचने पर पढ़े जाते हैं और इस प्रकार बड़ी संख्या में पुराने बिल्ड अनुरोधों को धीमा कर देते हैं

जेनकिंस को अपडेट करें। 2.107.1

• जेनकींस युद्ध फ़ाइल अपडेट करें
• Use browser for metadata download प्लगइन सुरक्षा सेटिंग अक्षम करें क्योंकि यह प्लगइन्स को अपडेट करने की अनुमति नहीं देगा
• नवीनतम उपलब्ध संस्करणों में प्लगइन्स अपडेट करें

संपादित करें 2018-03-18:

• मिमी . पर चलने वाले सभी नोड्स में दूसरा निष्पादक जोड़ा गया

*श्रीमान पर चल रहे सभी एजेंटों को प्राथमिकता दी

लोड के तहत अब मास्टर को और अधिक प्रतिक्रियाशील होना चाहिए। सभी का निर्माण पहले के 4h+ की तुलना में 2h के करीब होना चाहिए।

संपादित करें 2018-03-24:
विलम्ब के लिए खेद है, व्यस्त सप्ताह...

• jenkinsserver (elektra-jenkinsfile) में एक नया कार्य जोड़ा गया जो रेपो में पाए जाने वाले Jenkinsfile को चलाएगा (एक बार मौजूद होने पर)

संपादित करें 2018-03-28:

• सुरंग इकाई फ़ाइल को फिर से करें, अब यह पर्यावरण फ़ाइलों को पार्स करती है और इस प्रकार इसे कई लक्ष्यों को इंगित करने के लिए समायोजित किया जा सकता है
• डॉकटर चलाने में सक्षम दास के रूप में v2 सर्वर जोड़ा गया
  
  
  
  • v2 . पर जेनकींस उपयोगकर्ता जोड़ा गया
  
  
  • v2 . पर openjdk-9 स्थापित किया
  
  

संपादित करें 2018-03-29:

• जेनकिंस मास्टर पर यूलिमिट सेटिंग्स को ठीक करें

हालांकि मुझे पूरा यकीन है कि @ingwinlu या कोई पहले से ही इस पर है: ऐसा लगता है जैसे ryzen v2 गलत कॉन्फ़िगर किया गया है:

FATAL: Could not apply tag jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException: Command "git tag -a -f -m Jenkins Build #185 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185" returned status code 128:
stdout: 
stderr: 
*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <[email protected]>) not allowed

https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console से लेकिन हुआ कई मौकों पर।

अरे! माफ़ करना। इसमें कोई डिपो स्थापित नहीं है और इसे केवल एक डॉकटर होस्ट के रूप में कार्य करना चाहिए। मैं अतिरिक्त झंडे हटा दूंगा।
// संपादित करें: किया जाना चाहिए। उम्मीद है कि यह काफी था
//EDIT2: मैंने अभी के लिए test-docker को भी अक्षम कर दिया है क्योंकि यह स्पष्ट रूप से परीक्षण चलाने के लिए आवश्यक बिल्ड इमेज नहीं ढूंढ सकता है।

लेकिन धिक्कार है बात तेज़ है अगर इसे वास्तव में कुछ मिलता है जो इसे बना सकता है
// संपादित करें 3: परीक्षण-डॉकर को केवल डॉक-प्रीफ़ैब टैग के साथ नोड्स पर चलाने के लिए सक्षम किया गया और उस टैग को रेजेन को दिया गया

दुख की बात है कि समस्या मूल रूप से अपेक्षा से बड़ी प्रतीत होती है।

कुछ नौकरियों में उनके नोड्स हार्डकोड होते हैं। कुछ टैग पुराने हैं (जेसी नोड्स पर स्थिर)। कुछ कार्यों के लिए सही नोड्स की आवश्यकता नहीं होती है और जहां केवल सही नोड पर निष्पादित किया जाता है क्योंकि इसे वहां एक बार पहले निष्पादित किया गया था और सफलतापूर्वक बनाया गया था।

एक नए नोड (ryzen v2 नेटिव) की शुरूआत ने आवंटन को थोड़ा इधर-उधर कर दिया, भले ही यह नहीं होना चाहिए था।

कृपया कुछ अनपेक्षित व्यवहार की अपेक्षा करें जब तक कि सब कुछ वहीं चल रहा हो जहां वह फिर से था।

चेंजलॉग:

• नामित नोड्स, <os>-<hostname>-<buildenv>
• अक्षम elektra-multiconfig-gcc47-cmake-options
  यह वास्तव में पिछले कुछ समय से gcc47 स्लेव्स पर नहीं चल रहा है, gcc49 या gcc63 बिल्डिंग के मिश्रण के साथ जहां इसे शेड्यूल किया गया था। अगर इसे फिर से चालू किया जाता है तो इसे v2 . पर gcc63 सक्षम dockercontainer पर जाना चाहिए
• एक टन नौकरियों को फिर से प्राप्त किया (उनमें से कुछ छूट गए होंगे)
  
  
  
  • इलेक्ट्रा-टूडो को stable आवश्यकता थी, लेकिन सभी स्थिर नोड्स में वास्तव में sloccount स्थापित नहीं था
  
  
  • इसी तरह के और भी कई मामले
  
  

A7 नीचे लगता है

वाह अधिसूचनाएं @github.com schrieb am Do., 29. März 2018, 21:24:

हालांकि मुझे पूरा यकीन है @ingwinlu https://github.com/ingwinlu or
कोई पहले से ही इस पर है: ऐसा लगता है जैसे ryzen v2 गलत कॉन्फ़िगर किया गया है:

घातक: टैग जेनकींस-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185 लागू नहीं किया जा सका
hudson.plugins.git.GitException: कमांड "गिट टैग-ए-एफ-एम जेनकिंस बिल्ड #185 जेनकींस-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185" स्टेटस कोड 128 :
स्टडआउट:
स्टेडर:
* कृपया बताएं कि आप कौन हैं।

Daud

git config --global user.email " [email protected] "
git config --global user.name "आपका नाम"

अपने खाते की डिफ़ॉल्ट पहचान सेट करने के लिए।
Omit --global केवल इस रिपॉजिटरी में पहचान सेट करने के लिए।

घातक: खाली पहचान नाम ( [email protected] के लिए ) की अनुमति नहीं है

से
https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console
लेकिन कई मौकों पर हुआ।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377344978 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEOv-ifc-Ns9q0wuscPa3t8AMo15A07iks5tjTTcgaJpZM4DIApm
.

क्या आप उस पर काम करना चाहते हैं? मैं इसे आज रीबूट कर सकता था। वैकल्पिक रूप से हमारे व्यवस्थापक या मैं इसे मंगलवार को रीबूट कर सकते हैं।

अगर यह बहुत ज्यादा परेशानी की बात नहीं है। नहीं तो मैं अपने पीआर पर काम नहीं कर सकता
सप्ताहांत

मार्कस 2330 नोटिफिकेशन @github.com schrieb am Sa., 31. मर्ज़ 2018, 14:33:

क्या आप उस पर काम करना चाहते हैं? मैं इसे आज रीबूट कर सकता था। विकल्प के रूप में हमारा
व्यवस्थापक या मैं इसे मंगलवार को रीबूट कर सकता हूं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

ठीक है, मैंने इसे फिर से शुरू किया और BIOS/UEFI में C6-स्टेट को भी अक्षम कर दिया (सक्षम किया गया था)। मैंने gnome/xorg भी हटा दिया (मुझे लगा कि मैंने पहले ही ऐसा कर लिया है?)

बीटीडब्ल्यू। स्क्रीन पूरी तरह से काली थी, इसलिए हम केवल अनुमान लगा सकते हैं कि इसका कारण क्या था।

ये हर 10 मिनट में a7 पर पॉप अप कर रहे हैं:

Apr 04 07:14:23 a7 kernel: [Hardware Error]: Corrected error, no action required.
Apr 04 07:14:23 a7 kernel: [Hardware Error]: CPU:0 (17:1:1) MC15_STATUS[Over|CE|MiscV|-|AddrV|-|-|SyndV|-|CECC]: 0xdc
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Error Addr: 0x00000003705a2f00
Apr 04 07:14:23 a7 kernel: [Hardware Error]: IPID: 0x0000009600050f00, Syndrome: 0x0000015c0a400f03
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Extended Error Code: 0
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Error: DRAM ECC error.
Apr 04 07:14:23 a7 kernel: EDAC MC0: 1 CE on mc#0csrow#3channel#0 (csrow:3 channel:0 page:0x700b45 offset:0xf00 grain
Apr 04 07:14:23 a7 kernel: [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD
lines 5977-6036/6036 (END)

वे कारण हो सकते हैं a7 डाउनटाइम के साथ-साथ a7 लेटल्टी पर कुछ अजीब बिल्ड व्यवहार के कारण

elektra-ini-mergerequests में अक्षम वालग्रिंड अनुभाग क्योंकि इसे make run_memcheck माध्यम से चलाया गया था

ये हर 10 मिनट में a7 पर पॉप अप कर रहे हैं

हाँ, हम उन्हें पहले ही देख चुके हैं। जब कंप्यूटर खरीदा गया था, तो किसी ने वास्तव में जाँच की कि क्या ईसीसी काम करता है और उस समय ऐसी कोई त्रुटि नहीं हुई थी। क्या इन त्रुटियों की आवृत्ति किसी तरह सिस्टम के भार पर निर्भर करती है?

इलेक्ट्रा-इन-मर्जरेक्वेस्ट में अक्षम वालग्रिंड अनुभाग क्योंकि इसे रन_मेमचेक बनाने के माध्यम से चलाया गया था

इसे साफ करने के लिए धन्यवाद।

मैं a7 पर बिना किसी 'असली' लॉग के रैंडम आउटटेक (कंटेनर क्रैश हो रहा हूं, बीच में स्टॉप बनाता हूं, डिस्कनेक्ट करता हूं, ...) कर रहा हूं। केवल पहले ही उल्लेखित स्मृति सुधार।

धन्यवाद, ऐसा लगता है कि कुछ बहुत गलत है। और अब हमारे पास अचूक त्रुटियाँ भी हैं:

Apr  5 09:50:40 a7 kernel: [39549.503787] mce: Uncorrected hardware memory error in user-access at 73d6ce880
Apr  5 09:50:40 a7 kernel: [39549.503794] [Hardware Error]: Uncorrected, software restartable error.
Apr  5 09:50:40 a7 kernel: [39549.505882] [Hardware Error]: CPU:2 (17:1:1) MC0_STATUS[-|UE|MiscV|-|AddrV|-|Poison|-|-|UECC]: 0xbc002800000c0135
Apr  5 09:50:40 a7 kernel: [39549.506581] [Hardware Error]: Error Addr: 0x000000073d6ce880
Apr  5 09:50:40 a7 kernel: [39549.507287] [Hardware Error]: IPID: 0x000000b000000000
Apr  5 09:50:40 a7 kernel: [39549.507980] [Hardware Error]: Load Store Unit Extended Error Code: 12
Apr  5 09:50:40 a7 kernel: [39549.508677] [Hardware Error]: Load Store Unit Error: DC data error type 1 (poison consumption).
Apr  5 09:50:40 a7 kernel: [39549.509378] [Hardware Error]: cache level: L1, tx: DATA, mem-tx: DRD
Apr  5 09:50:40 a7 kernel: [39549.510136] Memory failure: 0x73d6ce: Killing java:1470 due to hardware memory corruption
Apr  5 09:50:40 a7 kernel: [39549.510908] Memory failure: 0x73d6ce: recovery action for dirty LRU page: Recovered

वहाँ a7 फिर से चला जाता है।

अधिक उत्पादक मोर्चे पर: मैंने जेनकींस के लिए ब्लू ओशन फ्रंटएंड स्थापित किया। पूर्वावलोकन

वहाँ a7 फिर से चला जाता है।

यह वास्तव में निराशाजनक है। मैंने मशीन को फिर से चालू किया और एजेंटों को फिर से जोड़ा। मैं अपने व्यवस्थापक से कल RAM बदलने के लिए कहूँगा, इसलिए कल डाउनटाइम की अपेक्षा करें।

अधिक उत्पादक मोर्चे पर: मैंने जेनकींस के लिए ब्लू ओशन फ्रंटएंड स्थापित किया। पूर्वावलोकन

अच्छा लग रहा है! हो सकता है कि आप इसे अगली बैठक में हमें दिखा सकें?

हमारा व्यवस्थापक पहले से ही सप्ताहांत में है। मैं a7 को रीबूट करूँगा और BIOS/UEFI को फ़ैक्टरी डिफ़ॉल्ट पर रीसेट करूँगा। यदि सप्ताहांत में त्रुटियां जारी रहती हैं तो वह उम्मीद से रैम का आदान-प्रदान करेगा।

संपादित करें: कोई निर्माण कार्य नहीं चल रहा था, इस प्रकार कोई निर्माण कार्य रद्द नहीं किया गया था।

संपादित करें: सब कुछ फिर से है। अभी तक कोई मेमोरी त्रुटि नहीं है।

बहुत बेहतर दिख रहा है। क्या किसी ने बहुत अधिक लाइनस टेक टिप्स देखे और सर्वर को ओवरक्लॉक किया?

क्षमा करें, मुझे जेनकिंस को कुछ समय के लिए रोकना पड़ा। सर्वर पर 20 लोड थे और जो चीजें मुझे करने की ज़रूरत थी वे अब संभव नहीं थीं (> 1h प्रतीक्षा समय, फिर मैंने जेनकींस को छोड़ दिया और बंद कर दिया)।

क्या यह संभव है कि गैर-शुरू किए गए निर्माण कार्यों में भी RAM की आवश्यकता हो? (कतार सूची बहुत लंबी थी) अन्यथा स्थानीय निर्माण कार्य इन समस्याओं के लिए सबसे अच्छे उम्मीदवार हैं। (3 स्थानीय निर्माण कार्य चल रहे थे)

@ingwinlu आदर्श रूप से, हम उस सर्वर पर कुछ भी नहीं बनाते हैं। इसके अलावा, क्या हम सर्वर पर लोड पर निर्भर बिल्ड जॉब बना सकते हैं। (लोड> 5 वाले सर्वर पर कार्य प्रारंभ न करें?)

मैंने सब कुछ फिर से शुरू किया लेकिन मुझे उम्मीद है कि हम इसके लिए एक त्वरित समाधान खोज लेंगे।

मैंने जेनकिंस सिस्टम सेटिंग्स में संस्करण और सीएमपीवर्शन को पंप किया।

@ingwinlu यह बहुत अच्छा होगा यदि हमारे पास ये सेटिंग्स जेनकिंसफाइल के भीतर भी हों।

@markus2330 जेनकिंसफाइल में इसे कैसे प्राप्त करें, इस पर एक उदाहरण के लिए

निम्नलिखित लक्ष्यों से make run_memcheck को हटा दिया गया क्योंकि वे कुछ समय से विफल हो गए और अंत में #1882 के लिए बिल्ड सिस्टम में दिखाई दे रहे थे

• gcc-configure-debian-stretch-minimal
• gcc-configure-debian-wheezy
• elektra-gcc-i386

नोड्स पर चलने के लिए elektra-gcc-configure-debian-stretch प्रतिबंधित करें: stretch && !mr

जेनकिंस मास्टर को ver. 2.107.2 अपडेट करें + सभी प्लगइन्स को अपडेट करें

मैंने आज सभी बिल्ड जॉब्स में allowMembersOfWhitelistedOrgsAsAdmin जोड़ने की कोशिश की, लेकिन ऐसा लगता है कि मैं अभी भी एक बिल्ड ऑल (# 1863 देखें) को ठीक से ट्रिगर नहीं कर सकता और केवल कुछ जॉब्स को ही निष्पादित किया जाता है

@markus2330 https://github.com/janinko/ghprb/issues/416#issuecomment -266254688

क्या कोई कृपया कर सकता है

• ठीक कर
• अक्षम करें, या
• (और भी बेहतर) हटाएं

elektra-clang-asan कृपया 🙏. वर्तमान में निर्माण कार्य विफल रहता है, हालांकि सभी असफल परीक्षण:

• testlib_notification
• testshell_markdown_base64
• testshell_markdown_ini
• टेस्टशेल_मार्कडाउन_मिनी
• टेस्टशेल_मार्कडाउन_टीसीएल
• testshell_markdown_xerces
• testshell_markdown_tutorial_validation

ट्रैविस पर ठीक काम करें।

वे उसी तरह परीक्षण नहीं करते हैं (उदाहरण के लिए) वे विभिन्न क्लैंग संस्करणों का उपयोग करते हैं ...

चूंकि यह धागा बग रिपोर्ट या लंबी चर्चा के लिए पूरी तरह से अप्राप्य है, जैसे ही मैं इसे प्राप्त करता हूं, मैं क्लैंग और क्लैंग-आसन के लिए नए मुद्दों को खोलूंगा।

वे उसी तरह परीक्षण नहीं करते हैं (उदाहरण के लिए) वे विभिन्न क्लैंग संस्करणों का उपयोग करते हैं ...

मैं, सहमत हैं कि यद्यपि ट्रैविस पुराना का उपयोग करता है clang 5.0.0 पर, बजना संस्करण elektra-clang-asan प्राचीन है ( 3.8.1 )। मुझे ऐसे पुराने कंपाइलर के लिए आसन सक्षम बिल्ड जॉब का मूल्य नहीं दिख रहा है।

मैंने "इलेक्ट्रा-क्लैंग-आसन" पर असफल "testlib_notification" परीक्षण के लिए #1919 बनाया।

मैंने सभी मिस्टर एजेंटों के साथ एक बिल्ड का परीक्षण किया और मास्टर पूरी तरह से उत्तरदायी था, जबकि सभी एमआर एजेंटों के साथ एक बिल्ड ने वास्तव में कुछ बिल्डों का समय समाप्त कर दिया। इसलिए #1866 निश्चित रूप से एक सुधार प्रदान करेगा यदि हम सभी मिस्टर एजेंटों से छुटकारा पा सकते हैं (-मट्ठा क्योंकि यह कंटेनर करने योग्य नहीं है)

आगे के परीक्षण से पता चलता है कि यह केवल मुखपृष्ठ ही नौकरी बनाता है। मैंने इसे अभी के लिए build all से हटा दिया है, इसलिए यह केवल स्पष्ट रूप से चलाया जाता है।

इसे कंटेनरीकृत घोल से बदल दिया जाएगा।

v2 नवीनतम BIOS के साथ फिर से ऑनलाइन है।

कृपया यहां किसी भी segfaults की रिपोर्ट करें (CPU छोटी गाड़ी हो सकती है)।

a7 नीचे लगता है?

मई 2018 11:10 पर पर 4, markus2330 [email protected] लिखा है:

v2 नवीनतम BIOS के साथ फिर से ऑनलाइन है।

कृपया यहां किसी भी segfaults की रिपोर्ट करें (CPU छोटी गाड़ी हो सकती है)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-386545292 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEOv-qhlMoQ78eNfpLpzXEBLTcq0pKT5ks5tvBsXgaJpZM4DIApm
.

a7 फिर से नवीनतम BIOS के साथ है

a7 फिर से नीचे?

हाँ, यह दुर्घटनाग्रस्त हो गया था। इसने बिना किसी त्रुटि संदेश के लॉगिन प्रॉम्प्ट दिखाया और किसी भी इनपुट (sys-req सहित) पर कोई प्रतिक्रिया नहीं हुई। केवल हार्ड-रीसेट ने मदद की।

यदि आपके पास कोई विचार है कि समस्या क्या हो सकती है, तो कृपया बताएं।

दुख की बात है कि कोई भी स्थायी पत्रिका a7 पर स्थापित नहीं है, इसलिए कोई लॉग नहीं है

हम कब a7 और v2 के फिर से उपलब्ध होने की उम्मीद कर सकते हैं?

ओह, मुझे नहीं पता था कि वे नीचे थे। मैं अपने व्यवस्थापक से रीबूट करने के लिए कहूंगा और यदि वह सक्षम नहीं है तो मैं इसे लगभग 17:00 बजे करूंगा।

संपादित करें: उन्होंने कहा कि वह उन्हें अभी रीसेट करेंगे।

संपादित करें: वे दोनों फिर से ऊपर हैं।

मैंने आज मैन्युअल रूप से a7 और v2 को रीबूट किया। ऐसा लगता है कि v2 अब उपलब्ध नहीं है। क्या आप कृपया कर सकते हैं यह वास्तव में चल रहा है?

// संपादित करें: दोनों मशीनों पर नेटवर्क कॉन्फ़िगरेशन को ठीक करके हल किया गया

जाहिर तौर पर a7 फिर से नीचे चला गया है।

ठीक है, मैं उसे फिर से चालू कर दूँगी। नहीं तो हम यह रिलीज कभी नहीं करवा पाएंगे।

कारण का कोई संकेत? सिर्फ नेटवर्किंग के मुद्दे या मशीन फिर से अनुत्तरदायी थी?

सब कुछ अब ऊपर और चलना चाहिए।

मैंने इसे सही समय पर प्राप्त किया, कुछ लॉग थे जब तक कि यह पूरी तरह से जम नहीं गया।

लॉग थे:

INFO: rcu_sched detected stalls on CPUs/tasks:
...
rcu_sched kthread starved for 7770 jiffies
watchdog: BUG soft lockup - CPU#2 stuck for 22s! [docker-gen]
... (many repetitions)
NMI watchdog: Watchdog detected hard LOCKUP on cpu 2

यह कुछ भी हो सकता है। दोषपूर्ण रेजेन सीपीयू से खराब पीएसयू तक :(

12 मई 2018 को 14:33 बजे, मार्कस 2330 नोटिफिकेशन @github.com ने लिखा:

सब कुछ अब ऊपर और चलना चाहिए।

मैंने इसे सही समय पर प्राप्त किया, अंत तक कुछ लॉग थे
पूरी तरह से फ्रीज।

लॉग थे:

जानकारी: rcu_sched ने CPU/कार्यों पर स्टालों का पता लगाया:
...
rcu_sched kthread 7770 पलों के लिए भूखा रहा
वॉचडॉग: बग सॉफ्ट लॉकअप - CPU#2 22s के लिए अटका हुआ है! [डॉकर-जीन]
... (कई दोहराव)
एनएमआई वॉचडॉग: वॉचडॉग ने सीपीयू पर हार्ड लॉकअप का पता लगाया 2

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

लगभग # 1993

@ingwinlu कृपया नौकरियों को अक्षम करें यदि वे वर्तमान में सफल नहीं होते हैं (या कम से कम उन्हें डिफ़ॉल्ट रूप से ट्रिगर न करें और न ही " बनाएं ")। यह उच्च प्राथमिकता होनी चाहिए कि हम पीआर में नौकरियों को विफल न करें जहां वास्तव में सब कुछ ठीक है। (काफी समय तक आसन का असफल होना अच्छी स्थिति नहीं थी)

यदि आपके द्वारा किए गए कुछ जेनकींस कार्रवाई के कारण वे विफल हो जाते हैं, तो नौकरियों को फिर से शुरू करना अच्छा होगा: दिल: यहां # 160 में ऐसा कहना भी ठीक है।

v2 फिर से शुरू हो गया है, नए CPU के साथ!

कृपया तनाव-परीक्षण के लिए अनेक कार्य सबमिट करें :मुस्कान:

a7 फिर से नीचे लगता है।

धन्यवाद, सब कुछ फिर से हो गया है।

मैंने a7 को फिर से शुरू किया।

एक सर्किट होने से जो हर घंटे a7 को रीसेट करता है, उपलब्धता में वृद्धि की संभावना है।

हम कब a7 को फिर से ऑनलाइन देखने की उम्मीद कर सकते हैं?

a7 ऑनलाइन वापस आ गया है

v2 ऑनलाइन वापस आ गया है

लगभग 1 घंटे में v2 की बिजली आपूर्ति का आदान-प्रदान किया जाएगा।

@ingwinlu क्या आप एजेंटों को अक्षम कर सकते हैं और बाद में उन्हें फिर से सक्षम कर सकते हैं? (यदि आप वर्तमान में इस पर काम कर रहे हैं।)

v2 एजेंट अभी के लिए अक्षम हैं

v2 फिर से चल रहा है। इसमें नई बिजली आपूर्ति है। कृपया मशीन को तनाव परीक्षण करने के लिए कई कार्य सबमिट करें।

मैंने जेनकींस प्लगइन्स को अपडेट किया। परिणामी रिबूट ने पुराने जेनकींस नोड्स को आंशिक रूप से बहाल कर दिया (इससे पहले उनका नाम बदल दिया गया था) जिसके परिणामस्वरूप हर जगह टूटा हुआ निर्माण हुआ क्योंकि गिट रिपॉजिटरी टूट गई थी।

मैंने प्रभावित रिपॉजिटरी को साफ किया और सुनिश्चित करने के लिए कैश्ड डॉकटर कंटेनरों को साफ किया।

a7 फिर से डाउन हो गया है और इस तरह डॉकर आधारित बिल्ड फिर से उपलब्ध नहीं हैं।

मैं अपडेट को xunit में भी वापस ला रहा हूं क्योंकि यह सुरक्षा प्रतिबंधों का उल्लंघन करता है।

मैंने a7 को रिबूट किया और सभी एजेंटों को फिर से जोड़ा।

डोकर बिल्ड उपलब्ध नहीं हैं क्योंकि a7 फिर से डाउन हो गया है।

मैंने सर्वर को रिबूट किया और एजेंटों को फिर से जोड़ा।

मुझे लगता है कि a7 को बदलना सबसे अच्छा तरीका है, देखें #2020

मुझे लगता है कि यह फिर से नीचे है, मेरी नवीनतम प्रतिबद्धता के परिणामस्वरूप a7-debian-stretch से संपर्क नहीं किया जा सकता: java.lang.InterruptedException

@e1528532 इसे यहाँ लिखने के लिए धन्यवाद! आप चाहें तो #2020 . में भी वोट कर सकते हैं

मैंने a7 को फिर से शुरू किया और एजेंटों को फिर से जोड़ा।
आइए हम अच्छे के लिए आशा करें कि सप्ताहांत के दौरान कोई समस्या न हो।

a7 फिर से नीचे है: रोना: आश्चर्य की बात है कि इसने लगभग पूरे सप्ताहांत में काम किया। सप्ताह का अपटाइम रिकॉर्ड हो सकता है। फिर भी #2020 को ज्यादा कमेंट्स नहीं मिले।

मैंने a7 को फिर से शुरू किया (इसने sysctl पर प्रतिक्रिया दी) और किसी और ने जेनकींस शुरू कर दिया। सब कुछ फिर से चल रहा है।

a7 बस फिर से नीचे चला गया।

जानकारी के लिए धन्यवाद! मैंने a7 को फिर से शुरू किया और एजेंटों को फिर से जोड़ा।

क्या यह समझ में आता है कि हमारे पास एजेंट "डेबियन-जेसी-मिनिमल" है? मुझे लगता है कि डॉकर में एकीकृत होने के बाद आप इसे सुरक्षित रूप से हटा सकते हैं। (और ऐसा लगता है जैसे यह पहले से ही है)

संपादित करें:
https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log में
और https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
चेतावनी हैं:

WARNING: LinkageError while performing UserRequest:hudson.Launcher$RemoteLauncher$KillTask<strong i="13">@544b40e</strong>
java.lang.LinkageError
    at hudson.util.ProcessTree$UnixReflection.<clinit>(ProcessTree.java:710)
    ...
Caused by: java.lang.ClassNotFoundException: Classloading from system classloader disabled
    at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:854)

बुरी खबर। v2 भी नीचे चला गया।

संपादित करें: लेकिन मुझे लगता है कि मैं इसे एसएसएच के माध्यम से कनेक्ट करने में सक्षम हूं ....
EDIT2: v2 पर रीबूट जारी किया लेकिन अब मैं कनेक्ट नहीं कर सकता। हालांकि अभी भी a7 से पिंग करने योग्य ...

EDIT3: अब a7 भी नीचे है।

रिपोर्टिंग के लिए धन्यवाद! मैंने a7 और v2 को रीबूट किया। हमें #2020 पर पुनर्विचार करना चाहिए।

मुझे लगता है कि v2 फिर से नीचे है:

V2-डेबियन-खिंचाव से संपर्क नहीं कर सकता: java.lang.InterruptedException

V2 के साथ सब कुछ ठीक था लेकिन a7 फिर से नीचे था। सभी एजेंट अब फिर से ऑनलाइन हैं।

v2 फिर से अर्ध अनुत्तरदायी प्रतीत होता है। a7 से पिंग करने योग्य लेकिन कोई ssh कार्रवाई बिल्कुल नहीं। केवल लक्षणों से btrfs मुद्दे होने चाहिए। क्या आप सप्ताहांत के लिए घर जाने से पहले सब कुछ रीबूट कर सकते हैं?

@ingwinlu धन्यवाद, @waht और मैंने v2 को सफलतापूर्वक रिबूट किया लेकिन मैं एजेंटों को कनेक्ट नहीं कर सकता ("कनेक्शन अस्वीकृत (कनेक्शन अस्वीकृत)")। कोई विचार यहाँ क्या गलत है? (इंटरैक्टिव एसएसएच लॉगिन काम करता है)

ssh केवल तभी काम करता है जब ब्रिज से कनेक्ट न हो।

ब्रिजिंग सेवा को फिर से शुरू करने के बाद कनेक्शन स्थापित किया जा सका।

ऐसा लगता है कि ssh-सुरंग एक अजीब अपरिभाषित अवस्था में समाप्त हो गई और उसने खुद को नहीं मारा। निश्चित नहीं है कि उसने खुद को क्यों नहीं मारा (सर्वरलाइवइंटरवल चालू है)।

मुझे v2 पर सभी कार्यस्थानों को मैन्युअल रूप से साफ़ करने की भी आवश्यकता थी क्योंकि fs दूषित हो गया था और उन पर सभी निर्माण कार्य विफल हो गए थे।

a7 नीचे लगता है। मुझे यकीन नहीं है कि मैं इसे सोमवार से पहले रीबूट कर सकता हूं।

मैंने a7 और v2 को पुनरारंभ किया। (v2 क्योंकि a7 पर त्रुटि संदेश थे कि यह v2 के लिए ssh ब्रिज नहीं बना सकता है। लेकिन v2 के पुनरारंभ होने के बाद भी वही त्रुटि संदेश आया। फिर भी, ssh ब्रिज काम करने लगता है। शायद कुछ निर्भरता (नेटवर्क?) गायब है a7 की बूटअप स्क्रिप्ट?)

हो सकता है कि a7 . की बूटअप स्क्रिप्ट में कुछ निर्भरता (नेटवर्क?)

नहीं यह वहाँ है।

यह ssh ब्रिज को v2 . में नहीं बना सकता

मेरा मानना ​​है कि यह व्यवहार तब होता है जब v2 कर्नेल अनुत्तरदायी होने लगता है (और इस प्रकार कोई आवक नेटवर्क कनेक्शन स्थापित नहीं किया जा सकता है)। अतीत में आपने v2 पर btrfs त्रुटियों को इंगित करने वाले लॉग का उल्लेख किया था।

मैं बाद में सीपीयू को बदलने के लिए बिल्ड सर्वर को शटडाउन के लिए तैयार करता हूं।

a7 और v2 फिर से वापस आ गए हैं (a7 नए CPU के साथ, v2 इसके रूट फाइल सिस्टम के साथ चेक किया गया)

जबकि यह दिन के दौरान बना रहा (लगातार निर्माण के साथ) ऐसा लगता है जैसे a7 बस फिर से नीचे चला गया।

हाँ, मैं कल सुबह पुनः आरंभ करूँगा।

हमें #2020 पर फिर से चर्चा करनी चाहिए।

मैंने a7 को पुनरारंभ किया। यह फिर से एक सीपीयू हैंग था।

a7 फिर से नीचे है।

धन्यवाद, मैंने इसे पुनः आरंभ किया। सभी एजेंट फिर से ऑनलाइन हैं।

ऐसा लगता है कि कुछ डेबियन नोड्स नीचे हैं और इस प्रकार कुछ पीआरएस परीक्षण निष्पादन शुरू होने के लिए पहले से ही लंबे समय से प्रतीक्षा कर रहे हैं। क्या इसका इरादा है?

ऐसा लगता है कि कुछ डेबियन नोड्स नीचे हैं और इस प्रकार कुछ पीआरएस परीक्षण निष्पादन शुरू होने के लिए पहले से ही लंबे समय से प्रतीक्षा कर रहे हैं। क्या इसका इरादा है?

एमएम-डेबियन-अस्थिर नोड पर अपग्रेड के दौरान मशीन अनुत्तरदायी हो गई और हम तब से इससे कनेक्ट नहीं हो पाए हैं। चूंकि मालिक हमारे ईमेल का जवाब नहीं दे रहा है, यह शायद हमेशा के लिए चला जाएगा।

जबकि हमने नई प्रणाली में अच्छी मात्रा में बिल्ड जॉब्स को पोर्ट किया है, पहले से ही गायब हैं जो वर्तमान में कतार में लटके हुए हैं।

मैंने प्रभावित नौकरियों को अक्षम कर दिया और उन्हें प्रतिस्थापित करने के लिए चिह्नित किया + दस्तावेज़ों से हटा दिया गया

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

अगर कोई रिज़ॉल्वर पर काम करना चाहता है तो xdg टेस्ट पढ़ना काफी महत्वपूर्ण है। मैंने इसे यहां शीर्ष पद पर जोड़ा है। क्या आप ऊपर दी गई जांच सूची में जो हासिल कर चुके हैं उसे अपडेट कर सकते हैं?

इस बार v2 भाग्यशाली विजेता है।

@ मार्कस 2330 मैंने शीर्ष पद को साफ किया।

सफाई के लिए धन्यवाद! मैं कल सुबह v2 (और शायद a7, देखते हैं) को फिर से चालू करूँगा।

मैंने इसे रिबूट किया। कोई प्रतिक्रिया नहीं थी और कोई संदेश नहीं था। देखें #2020

कृपया a7 और v2 को रीबूट करें।

मैंने a7 को रिबूट किया। मुझे v2 के साथ कोई समस्या नहीं मिली, क्या मुझे इसे वैसे भी रीबूट करना चाहिए?

i7 अब 192.168.173.96 पर उपलब्ध है क्या आप कृपया a7 के माध्यम से एक पुल बना सकते हैं?

आपको मशीन पर एक ssh-tunnel-a7-v2 उपयोगकर्ता बनाने या मेरे लिए एक खाता बनाने की आवश्यकता है।

हमने एक अतिरिक्त बिल्ड स्लेव i7-debian-stretch जोड़ा है जो libelektra बिल्डजॉब्स में मदद करेगा।

v2-docker-buildelektra-stretch (offline) रूप में वहाँ कोई और निर्माण कार्य निर्धारित नहीं हैं। एजेंट को उजागर करने वाले a7 पर ssh-bridge को भी अक्षम कर दिया गया है।

हैलो @ingwinlu ,
जैसा कि पिछली बैठक में चर्चा की गई थी, मुझे पहुंच बिंदु की आवश्यकता होगी।
क्या आप कृपया मुझे प्रति ईमेल जानकारी भेज सकते हैं, मेरा ईमेल AUTHORS.md में है ।
बीटीडब्ल्यू। आपका ईमेल कहीं भी नहीं मिला, हो सकता है कि आपको इस फ़ाइल में स्वयं को जोड़ना चाहिए।

हमारा v2 बिल्ड सर्वर 31.07 09:00 तक ऑफलाइन रहेगा क्योंकि हम इस पर बेंचमार्क चला रहे हैं। लंबे निर्माण समय की अपेक्षा करें।

असुविधा के लिए खेद है।

// संपादित करें: डाउनटाइम को 2 घंटे तक बढ़ाया गया

लगता है अब एक्सटेंशन भी पास हो गया है। दोपहर के भोजन के बाद (लगभग 13:00) फास्ट बिल्ड को वापस करना अच्छा होगा। :मुस्कुराओ:

mm-debian-unstable को अपग्रेड किया गया था और यह ऑनलाइन वापस आ गया है। क्या ऐसे कार्य हैं जिन्हें हम पुनः सक्रिय कर सकते हैं और सर्वर पर पिन कर सकते हैं?

ऐसा लगता है जैसे i7 की डिस्क भर गई है। मेरी नौकरियां No space left on device ( नौकरी और नौकरी ) के साथ विफल हो जाती हैं

मुझे वास्तव में नया बिल्ड इंटरफ़ेस (dockerization & jenkinsfile) पसंद है। बिल्ड त्रुटियों को पुन: उत्पन्न करने के लिए बहुत उपयोगी है।

रिपोर्टिंग के लिए धन्यवाद!

दुर्भाग्य से आकार बदलने के लिए एक पुनरारंभ की आवश्यकता होगी (रूटफ़्स को दूसरे को विस्तारित करने से पहले छोटा करने की आवश्यकता है) और केवल 20G लाएगा। मैंने जेनकिंस बिल्ड फोल्डर को हटा दिया लेकिन वे छोटे थे, इसलिए हम अभी भी 99% पर हैं।

तो सफाई _docker अधिक प्रभावी होगी:
@ingwinlu ऐसा लगता है कि दोनों _docker/overlay2 बहुत बड़ा है। कोई विचार क्यों यह सब सामान वहाँ एकत्र किया गया था?

मैं docker system prune -fa साथ साफ किए गए डॉकटर कलाकृतियों को मजबूर करता हूं। इस
डॉकर छवियों में प्रयुक्त लगभग 190GB स्थान को साफ किया।

सोम, 13 अगस्त 2018 को 07:54 बजे, मार्कस2330 नोटिफिकेशन @github.com ने लिखा:

रिपोर्टिंग के लिए धन्यवाद!

दुर्भाग्य से आकार बदलने के लिए पुनरारंभ की आवश्यकता होगी (रूटफ़्स को बनाने की आवश्यकता है
इससे पहले कि दूसरे को छोटा किया जा सके) और केवल 20G लाएगा। मैं
जेनकिंस बिल्ड फोल्डर को हटा दिया लेकिन वे छोटे थे, इसलिए हम अभी भी हैं
99%।

तो सफाई _docker अधिक प्रभावी होगी:
@ingwinlu https://github.com/ingwinlu दोनों _docker/overlay2 जैसा लगता है
ये बहुत बड़ा है। कोई विचार क्यों यह सब सामान वहाँ एकत्र किया गया था?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412415127 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEOv-oK9dSc27dbXOwgSq4xSWa4IXwiUks5uQRSwgaJpZM4DIApm
.

शुक्रिया!

क्या हम इसे परिवाद-दैनिक या क्रोनजॉब में डाल सकते हैं?

डेली कुछ ऐसा ही करता है लेकिन कम आक्रामक। दूसरा लेना होगा
देखो जब मैं विएना में वापस आता हूँ।

मार्कस2330 नोटिफिकेशन @github.com schrieb am Mo., 13. अगस्त 2018, 09:22:

शुक्रिया!

क्या हम इसे परिवाद-दैनिक या क्रोनजॉब में डाल सकते हैं?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRiIC7Mhks5uQSkzgaJpZM4DIApm
.

जैसा कि आपने देखा होगा कि बिल्ड सर्वर सुबह (कोई भी रात में) डाउन था। बिजली आपूर्ति इकाई क्षतिग्रस्त हो गई थी और अब इसे बदल दिया गया है।

इसके अलावा a7 या v2 अगले सप्ताह में छोटी अवधि के लिए बेंचमार्क के लिए ऑफ़लाइन हो सकते हैं। यदि एंटोन बेंचमार्क शुरू करता है तो आपको ऑफ़लाइन-संदेश "बेंचमार्क" दिखाई देगा। यदि कंप्यूटर बहुत अधिक समय तक ऑफ़लाइन रहता है (उदाहरण के लिए एक दिन से अधिक) तो कृपया हमसे संपर्क करें। (तब इसे फिर से ऑनलाइन टॉगल करना भूल गया होगा।)

हमारी साइड इमेज के साथ एक समस्या का समाधान किया।

testkdb_allplugins डेबियन-अस्थिर-पूर्ण-क्लैंग परीक्षणों के दौरान हमारी सिड छवि में segfaulted लेकिन केवल v2 पर निष्पादित होने पर। मैंने नवीनतम उपलब्ध पैकेजों का उपयोग करने के लिए छवि को मैन्युअल रूप से अपडेट किया और इसे हमारी रजिस्ट्री पर धकेल दिया।

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ पास हो गए हैं, लेकिन इस पर नजर रखेंगे।

इस मुद्दे का उल्लेख #2216 और #2215 ( @mpranj @sanssecours) में किया गया है।

मैंने अपनी डॉकटर रजिस्ट्री में सार्वजनिक पहुंच को लागू किया। इसे एक्सेस करने के तरीके के बारे में कुछ दस्तावेज़ों के लिए यहां देखें।

अगर कुछ उम्मीद के मुताबिक काम नहीं करता है तो मुझे बताएं।

// संपादित करें ऐसा लगता है जैसे लॉगिन सफल होने पर भी धक्का देना काम नहीं करता है।
//EDIT2 सार्वजनिक पहुंच फिर से अक्षम कर दी गई है। https://github.com/moby/moby/issues/18569। सिस्टम बनाने के लिए बहाल कार्यक्षमता
//EDIT3: हब-public.libelektra.org पर सार्वजनिक रेपो फिर से शुरू हो गया है

एंटोन कंप्यूटर के मेनबोर्ड को बदलना चाहता है जहां हाइपर-थ्रेडिंग अगले मंगलवार या बुधवार को निष्क्रिय हो जाती है (हम चुन सकते हैं)। क्या किसी को इन दो दिनों में से किसी एक पर बिल्डर की जरूरत है?

मैंने डॉकर रजिस्ट्री को पुनरारंभ किया और मैन्युअल रूप से क्लीनअप चलाया। उम्मीद है कि वेबसाइट छवि के साथ किसी भी निर्माण के मुद्दों को हल किया।

@ingwinlu रखरखाव के काम के लिए धन्यवाद!

दुर्भाग्य से वेबयूआई चरण काफी विश्वसनीय रूप से विफल हो जाता है, उदाहरण के लिए 321 या 320 (पहले भी विफल रहा लेकिन वेबयूआई को खींचते समय भी?)

मैं अधिक से अधिक आश्वस्त हूं कि मास्टर पर नौकरियों को रद्द करना एक बुरा विचार है। हमारे पास मास्टर पर लगभग कोई सफल बिल्ड नहीं है क्योंकि नेटवर्क की समस्याओं के कारण बिल्ड या तो रद्द कर दिए गए हैं या विफल हो गए हैं। प्रतिबद्ध इतिहास में यह बताना कठिन है कि क्या हुआ क्योंकि किसी भी तरह से उन्हें केवल विफलता के रूप में दिखाया गया है।

वर्कअराउंड के रूप में मैंने c3b59ecef95287ffc33b094b37e03d0ec6b5710f में अविश्वसनीय चरणों को अक्षम कर दिया, लेकिन मुझे आशा है कि हम उन्हें जल्द ही फिर से सक्षम कर सकते हैं!

क्या बेंचमार्क के लिए a7-debian-stretch अभी भी ऑफ़लाइन होना चाहिए? (21 फरवरी, 2019 10:47:56 पूर्वाह्न से ऑफ़लाइन लिया गया)

रिपोर्टिंग के लिए धन्यवाद! ऐसा लगता है जैसे एंटोन पुनः सक्रिय करना भूल गया। मैंने नोड को फिर से सक्रिय किया और मैंने पुराने नोड्स को भी हटा दिया (मिमी को छोड़कर क्योंकि वे अभी भी चल रहे हैं)।

सुबह सर्वर डाउन हो गया था। सब कुछ फिर से चलता है लेकिन हमें एक प्रस्ताव मिला कि वे हार्डवेयर का आदान-प्रदान करेंगे। तो सबसे अधिक संभावना है कि आज हमारे पास लगभग एक घंटे का एक और डाउनटाइम होगा।

सर्वर फिर से चालू हो गया है। दुर्भाग्य से हमें वही हार्डवेयर मिला। अगर किसी के पास इंस्टालेशन/सेटअप के लिए समय है, तो हम हार्डवेयर को अपग्रेड कर सकते हैं।

ऐसा लगता है कि जेनकींस का निर्माण काफी धीमा है (पूर्ण निर्माण के लिए कई घंटे)। जहाँ तक मैं बता सकता हूँ, केवल a7-debian-stretch और i7-debian परीक्षण निष्पादित कर रहे हैं, जबकि अन्य सभी नोड निष्क्रिय हैं। क्या यह अपेक्षित व्यवहार है?

इस समस्या की रिपोर्ट करने के लिए धन्यवाद!

नहीं, यह अपेक्षित व्यवहार नहीं है। ऐसा लगता है जैसे v2 नीचे है। मैं इसे जल्द से जल्द रीबूट कर दूंगा।

v2 अब फिर से ऊपर होना चाहिए

v2 नीचे है और मुझे डर है कि यह सोमवार तक ऐसा ही रहेगा। तब तक निर्माण बहुत धीमा होगा।

v2 फिर से एक नए मेनबोर्ड के साथ आया है

मैं #2852 से बचने के लिए सभी 3 बिल्ड एजेंट (i7, v2, a7, उसी क्रम में) को बस्टर में अपग्रेड कर दूंगा

मैं डाउनटाइम को यथासंभव न्यूनतम रखने की कोशिश करूंगा। निर्माण कार्य विफल हो सकते हैं, कृपया उन्हें पुनः आरंभ करें (एजेंटों के फिर से उठने के बाद)।

i7-डेबियन-बस्टर, पूर्व i7-डेबियन-खिंचाव फिर से ऑनलाइन है

v2 अगला है

v2-डेबियन-बस्टर और a7-डेबियन बस्टर भी फिर से ऑनलाइन हैं

मैंने मास्टर पर पिछले सफल निर्माण कार्य को फिर से शुरू किया, यह देखने के लिए कि क्या सब कुछ फिर से काम करता है:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

इसके अलावा, मैंने बस्टर बिल्ड जॉब को सक्षम करने के लिए पीआर https://github.com/ElektraInitiative/libelektra/pull/2876 जोड़ा।

v2 नीचे लगता है (ssh कनेक्शन भी विफल रहता है), दुर्भाग्य से मैं वियना में नहीं हूं। मुझे उम्मीद है कि हमारा sysadmin कल इसे ठीक कर देगा।

a7 अब भी नीचे है और इसके साथ i7 (जो a7 पर ब्रिज के माध्यम से जुड़ा हुआ है)।

इसलिए वर्तमान में कोई निर्माण नहीं किया जा सकता है। मैंने व्यवस्थापक से संपर्क किया।

सभी सर्वर फिर से चालू हो गए हैं। कृपया अपने पीआर पर टिप्पणी के रूप में या तो नए कमिट्स को पुश करके या "जेनकिंस बिल्ड लिबेलेक्ट्रा प्लीज" लिखकर बिल्ड को फिर से शुरू करें।

तकनीकी नोट: a7 "वॉचडॉग बग सॉफ्ट लॉकअप" के कारण डाउन हो गया। मैंने "nomodeset nmi_watchdog=0" जोड़ने का प्रयास किया। आइए आशा करते हैं कि वे फिर से उतने अस्थिर नहीं होंगे जितने पहले थे।

a7 (और v2 और i7 भी क्योंकि वे a7 पर एक पुल के माध्यम से जुड़े हुए हैं) नीचे हैं। मैंने अपने व्यवस्थापक से संपर्क किया। कृपया अभी निर्माण शुरू करने से बचने का प्रयास करें, क्योंकि यह केवल एक लंबी कतार बनाएगा।

a7 ऑनलाइन वापस आ गया है (पहले से ही कल था), v2 प्रभावित नहीं हुआ था

बिल्ड सर्वर स्थिति पृष्ठ के अनुसार सर्वर:

• a7-debian-buster ,
• i7-debian-buster , और
• v2-debian-buster

नीचे हैं। जेनकींस डेटा निर्देशिका भी बहुत भरी हुई प्रतीत होती है। और जब हम इस पर हैं: यह बहुत अच्छा होगा, अगर हम जेनकिंस और इसके प्लगइन्स को अपग्रेड कर सकें। मुझे इन समस्याओं को ठीक करने में दिलचस्पी है। हालांकि दो समस्याएं हैं।

1. मेरे पास सर्वरों को प्रशासित करने का अधिक (या वास्तव में कोई) अनुभव नहीं है।
2. मुझे शायद मशीनों तक भौतिक पहुंच की आवश्यकता होगी, क्योंकि वे काफी अस्थिर प्रतीत होती हैं।

a7 i7 और v2 के लिए एक सेतु है, इसलिए a7 के नीचे होने के कारण हम i7 और v2 के बारे में नहीं जानते हैं।

पहुंच कोई समस्या नहीं है, मैं इसे आपको दे सकता हूं। लेकिन आपको पता होना चाहिए कि जेनकिंस को अपग्रेड करना एक बड़ा ऑपरेशन है क्योंकि इसमें आमतौर पर जेनकिंस को फिर से कॉन्फ़िगर करने की आवश्यकता होती है (रिलीज नोट्स के अनुसार, जो कि कई हैं जिन्हें हमने कुछ समय से अपग्रेड नहीं किया है) और जेनकिंसफाइल को ठीक करने के लिए (प्लगइन से एपीआई परिवर्तन के अनुसार) ) यदि आप पहुंच चाहते हैं तो मुझे एक ईमेल छोड़ दें।

a7 (और अन्य सभी) फिर से ऊपर हैं।

a7 फिर से डाउन है, मैंने व्यवस्थापक से संपर्क किया।

तकनीकी नोट: a7 "वॉचडॉग बग सॉफ्ट लॉकअप" के कारण डाउन हो गया।

एक त्वरित खोज से पता चलता है कि यह एक BIOS समस्या हो सकती है। क्या किसी ने जाँच की कि क्या BIOS अद्यतन उपलब्ध हैं?

a7 i7 और v2 के लिए एक सेतु है, इसलिए a7 के नीचे होने के कारण हम i7 और v2 के बारे में नहीं जानते हैं।

यह एक खराब डिजाइन की तरह लगता है। क्या इसके आसपास कोई रास्ता नहीं है?

एक त्वरित खोज से पता चलता है कि यह एक BIOS समस्या हो सकती है। क्या किसी ने जाँच की कि क्या BIOS अद्यतन उपलब्ध हैं?

हमने एक नया BIOS स्थापित किया, सीपीयू को बदल दिया और कर्नेल को अपग्रेड किया (ऊपर संदेश देखें)। तब से व्यवस्था स्थिर थी। अब डेबियन बस्टर में अपग्रेड करने के बाद यह फिर से अस्थिर है।

फिर भी, मैंने व्यवस्थापक से पूछा कि क्या कोई नया BIOS उपलब्ध है।

यह एक खराब डिजाइन की तरह लगता है। क्या इसके आसपास कोई रास्ता नहीं है?

i7 और v2 एक निजी नेटवर्क में हैं क्योंकि पर्याप्त IPv4 पते नहीं हैं। मैंने अपने व्यवस्थापक से पूछा कि क्या शायद IPv6 सेटअप संभव होगा।

मैंने अपने व्यवस्थापक से पूछा कि क्या शायद IPv6 सेटअप संभव होगा।

हमें वास्तव में IPv6 की आवश्यकता नहीं है, यह ब्रिज के रूप में एक और अधिक स्थिर सर्वर का उपयोग करने के लिए पर्याप्त होगा।

सबसे अधिक संभावना है, v2 a7 की तरह अस्थिर है (केवल एक दुर्घटना थी लेकिन यह बहुत कुछ नहीं कहता है क्योंकि तुरंत जब a7 मर जाता है, तो यह v2 का भार लेता है)। हम i7 को ब्रिज की तरह इस्तेमाल कर सकते हैं। लेकिन अगर v2 और a7 नीचे चला जाता है, तो i7 भी ज्यादा काम का नहीं है, बिल्ड कार्य को पूरा करने में कई घंटे लगेंगे। इसके अलावा, i7 में डॉकर रजिस्ट्री के लिए पर्याप्त जगह नहीं है।

तो यह परिवर्तन थोड़े लाभ के साथ बहुत प्रयास होगा।

a7 और v2 की वास्तविक समस्या को ठीक करना कहीं अधिक आशाजनक है।

इसके अलावा, i7 में डॉकर रजिस्ट्री के लिए पर्याप्त जगह नहीं है।

उस स्थिति में एकमात्र समाधान a7 को ठीक करना है।

दुर्भाग्य से a7 फिर से नीचे है :रो:

मैंने पुराने कर्नेल के साथ बूट करने की कोशिश की लेकिन इससे कोई फायदा नहीं हुआ।

BIOS के लिए कुछ अन्य संस्करण उपलब्ध हैं लेकिन उनके जारी नोटों के अनुसार इस बात की बहुत कम उम्मीद है कि वे इस समस्या को ठीक कर देंगे और अगर यह खराब हो जाता है तो फिर से डाउनग्रेड करने का कोई तरीका नहीं है ...

a7 के लिए BIOS वर्तमान में अपग्रेड किया गया है। इसके अलावा, हम बैकपोर्ट से एक नए कर्नेल का उपयोग करने का प्रयास करेंगे।

a7 उम्मीद है कि जल्द ही फिर से उठ जाएगा।

नए BIOS ने मदद नहीं की, अब a7 मिनटों में क्रैश हो गया।

a7 फिर से डाउन है, मैंने व्यवस्थापक से संपर्क किया। बैकपोर्ट के नए कर्नेल को अगले रिबूट में आजमाया जाएगा।

a7 5.2 कर्नेल के साथ फिर से ऊपर है

मुझे लगता है कि यह फिर से दुर्घटनाग्रस्त हो गया ...

क्या हमें अभी भी वही त्रुटि संदेश मिलते हैं या कम से कम कुछ परिवर्तन हुआ है?

हाँ, a7 फिर से, मैंने व्यवस्थापक को सूचना दी। पुनरारंभ करते समय वह हमें संदेशों के बारे में बताएगा।

क्या किसी के पास दूसरा विचार है? (हमने पहले ही BIOS और कर्नेल को अपग्रेड कर लिया है।)

कुछ स्रोत नोव्यू ग्राफिक्स ड्राइवर के साथ समस्याओं का सुझाव देते हैं और हमें कोशिश करनी चाहिए nouveau.modeset=0 (किसी तरह यह nomodeset )। साथ ही BIOS में "C-states" को अक्षम करने का सुझाव दिया गया था।

हाँ, a7 फिर से, मैंने व्यवस्थापक को सूचना दी। पुनरारंभ करते समय वह हमें संदेशों के बारे में बताएगा।

क्या किसी के पास दूसरा विचार है? (हमने पहले ही BIOS और कर्नेल को अपग्रेड कर लिया है।)

शायद यह निर्धारित करने के लिए कि क्या यह केवल तब होता है जब मशीन पर 'वास्तविक' लोड होता है, यह निर्धारित करने के लिए a7 को जेनकींस दास के रूप में अक्षम कर सकता है।

@ingwinlu धन्यवाद, अच्छा विचार। मैंने अब एक बिल्ड जॉब को a7 (यह 2 था) में घटा दिया। सप्ताहांत के लिए (एक बार जब व्यवस्थापक ने कार्यालय छोड़ दिया) तो मैं एजेंट को पूरी तरह से अक्षम कर दूंगा।

@kodebach : धन्यवाद, मैं व्यवस्थापक को जानकारी अग्रेषित करूंगा।

क्या कोई समयरेखा है जब a7 फिर से होगा?

a7 फिर से ऊपर है, हाइपरथ्रेडिंग बंद है और केवल एक समवर्ती निर्माण कार्य है।

हम alpine और ubuntu-xenial बिल्ड को सिरस में ले जाकर, a7 से कुछ भार भी हटा सकते हैं। वे दोनों सरल "बिल्ड एंड टेस्ट" रन हैं। वे रिपोर्टिंग कवरेज जैसा कुछ खास नहीं कर रहे हैं।

साइरस प्रति उपयोगकर्ता 8 समवर्ती लिनक्स बनाता है । वर्तमान में linkchecker बिल्ड सिरस पर एकमात्र लिनक्स बिल्ड है।

वास्तव में ubuntu-xenial थोड़ा बेमानी है, क्योंकि हमारा ट्रैविस बिल्ड उबंटू ज़ेनियल पर चलता है।

सुझावों के लिए धन्यवाद लेकिन हम जेनकिंस से दूर किसी भी लिनक्स-बिल्ड को ऑफलोड करने की योजना नहीं बनाते हैं। इसके विपरीत, @Mistreated हमारे जेनकींस के बुनियादी ढांचे को और अधिक अद्यतित और उपयोगी बनाने के लिए काम करेगा (उदाहरण के लिए अधिक पैकेज बनाकर)। हमारे जेनकींस के फायदे हैं:

1. हमारे पास यह पूरी तरह से हमारे नियंत्रण में है
2. हम इसे आसानी से बढ़ा सकते हैं (बिल्ड एजेंटों पर केवल जावा + डॉकर की आवश्यकता होती है)
3. जेनकिंसफाइल बहुत साफ-सुथरा है और (अधिकांश भागों के लिए) काफी आसानी से एक्स्टेंसिबल है

लेकिन निश्चित रूप से, साइरस (या कोई अन्य अतिरिक्त निर्माण प्रणाली जो मुफ्त में दी जाती है, # 1540 देखें) का विस्तार करने के लिए सभी का स्वागत है।

यह सिर्फ एक अस्थायी समाधान के रूप में था, हाइपरथ्रेडिंग को अक्षम करने और a7 पर 1 समवर्ती नौकरी तक सीमित करने के लिए।

a7 केवल एक छोटा सा हिस्सा (लगभग 2/5) बनाता है, इसलिए आधे की कमी मुश्किल से ध्यान देने योग्य होनी चाहिए। या अब कोई विशेष समस्या है? (फिलहाल, निश्चित रूप से, डाउनटाइम से कई नौकरियों को पकड़ने में समय लगता है।)

a7 केवल एक छोटा सा हिस्सा बनाता है (लगभग 2/5)

2/5 40% है। मैं इसे एक छोटा सा हिस्सा नहीं मानूंगा।

या अब कोई विशेष समस्या है?

नहीं, वास्तव में ऐसा लगता है कि यह पहले से बेहतर काम कर रहा है।

क्षमा करें, मेरा मतलब लगभग 2/6 (1/6 i7 है, 3/6 v2 है)। और यह हिस्सा हटाया नहीं जाता बल्कि घटाया जाता है।

नहीं, वास्तव में ऐसा लगता है कि यह पहले से बेहतर काम कर रहा है।

उत्तम!

ऐसा लगता है कि a7 फिर से नीचे है ।

शुक्रिया! मैंने इसकी सूचना दी।

भविष्य में यह बहुत अच्छा होगा यदि जो पहले पता लगाता है वह सीधे इसकी रिपोर्ट कर सकता है

complang.tuwien.ac.at . पर हर्बर्ट

यह कहना काफी है, कि "ए7 इस्ट लीडर निच्ट एरेइचबार"।

और फिर इसकी रिपोर्ट भी यहाँ करें, ताकि हरबर्ट को कई ईमेल न मिलें।

निश्चित रूप से जेनकिंस मास्टर सर्वर को स्वचालित रूप से ऐसा ईमेल भेजने का एक तरीका है और शायद इस गिटहब मुद्दे पर भी पोस्ट करें। यह बहुत अजीब होगा, अगर इतने आसान काम के लिए जेनकींस प्लगइन नहीं था ...

हां, https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin है लेकिन मुझे यकीन नहीं है कि यह वही करता है जो हम चाहते हैं। जब कोई एजेंट को जानबूझकर बंद कर देता है तो यह ईमेल भी भेज सकता है। और एक व्यक्तिगत ईमेल को व्यवस्थापक द्वारा जल्दी से संभालने की अधिक संभावना है।

अगर हम कुछ स्वचालित करते हैं, तो सीधे पीसी की रीबूटिंग यदि वे पहुंच योग्य नहीं हैं (शायद उनके पास किसी प्रकार का वॉचडॉग भी अंतर्निहित है?)

a7 को पुनः आरंभ किया गया है और "वैश्विक C-राज्य नियंत्रण" अक्षम किया गया है।

हालाँकि, यह बिल्ड एजेंट के रूप में ऑनलाइन नहीं है।

आइए देखें कि क्या यह बिना लोड के भी दुर्घटनाग्रस्त हो जाता है। v2 और i7 फिर से काम करते हैं।

व्यवस्थापक (हर्बर्ट) कल उपलब्ध नहीं है, इसलिए मैं अभी के लिए बिल्ड एजेंट के रूप में a7 छोड़ देता हूं।

मेरी योजना (यदि पहले कोई विरोध या a7 क्रैश नहीं हुआ है) कल a7 को बिल्ड एजेंट के रूप में चालू करना है। यदि a7 फिर से दुर्घटनाग्रस्त हो जाता है, तो हर्बर्ट शुक्रवार को a7 को पुनः आरंभ कर सकता है। यह ठीक है?

यदि कतार बहुत लंबी नहीं है, तो मुझे लगता है कि हमें बिल्ड एजेंट को a7 पर थोड़ी देर के लिए अक्षम रखना चाहिए। आखिरी दुर्घटना 3 दिन बाद हुई थी। अगर हम इसे कल सक्षम करते हैं, तो हम यह नहीं जान पाएंगे कि बिल्ड एजेंट ने दुर्घटना का कारण बना या नहीं, जब तक कि यह तब तक दुर्घटनाग्रस्त न हो जाए।

ठीक है, तो देखते हैं कि कतार का आकार कैसा दिखता है।

मुझे उम्मीद है कि "वैश्विक सी-स्टेट कंट्रोल" अंततः समस्या को ठीक कर देगा और मुझे लगता है कि हमें इसका परीक्षण करने के लिए उच्च भार की आवश्यकता है।

कतार बहुत लंबी थी और मास्टर बिल्ड सभी लटके हुए थे क्योंकि उन्हें वेबसाइट परिनियोजन के लिए a7 की आवश्यकता थी।

इसलिए मैंने a7 एजेंट फिर से शुरू किया।

मुख्य बिल्ड सर्वर पर डिस्क स्थान अनुपलब्ध होने के कारण हाल ही के कुछ जेनकींस बिल्ड कार्य रद्द कर दिए गए थे। मैंने पुरानी बिल्ड नौकरियों के लॉग हटाकर कुछ जगह खाली कर दी। कृपया ध्यान दें कि मैंने नई बिल्ड नौकरियों की कुछ लॉग फाइलें भी हटा दी होंगी। कुछ मामलों में आपकी नवीनतम प्रतिबद्धता के लिए जेनकींस का निर्माण विफल हो सकता है और अब आप केवल 404 त्रुटि के अलावा कुछ संदेश देखते हैं। उस स्थिति में, कृपया बस या तो

• जेनकिंस बिल्ड को फिर से शुरू करने के लिए पीआर के नीचे एक टिप्पणी में jenkins build libelektra please का उपयोग करें, या
• परिवर्तनों के बिना अंतिम प्रतिबद्धता को फिर से लिखें (उदाहरण के लिए git commit --amend का उपयोग करके) और एक बल पुश करें

. असुविधा के लिए खेद है।

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

मैंने नोड v2-debian-buster को अस्थायी रूप से ऑफ़लाइन के रूप में चिह्नित किया है, क्योंकि यह सही ढंग से काम नहीं कर रहा है। अधिक जानकारी के लिए, कृपया अंक #2995 (और अंक #2994) पर एक नज़र डालें।

बुनियादी ढांचे की तलाश के लिए धन्यवाद!

v2 डिस्क स्थान से बाहर था। मैंने docker system prune निष्पादित किया कुल पुनः प्राप्त स्थान: 58.37GB

फिर मैंने v2 को रीबूट किया और एजेंट को फिर से कनेक्ट किया।

अब मैंने अन्य फ़ाइलों को निकालने के लिए du -h | sort -h निष्पादित किया है।

मैंने एक नए डॉकर संस्करण के साथ फिर से v2 शुरू किया। टूटे हुए निर्माण की सूचना तत्काल दें।

मैंने डॉकटर को फिर से स्थापित किया, सभी कॉन्फिग को शुद्ध किया और /var/lib/docker. उम्मीद है कि यह इसे ठीक करता है।

v2 को फिर से शामिल किया जाएगा। कृपया टूटे हुए बिल्ड की तुरंत रिपोर्ट करें।

जैसा कि यहां सुझाव दिया गया

ethtool -K enp3s0 sg off # on v2
ethtool -K enp0s25 sg off # on i7
ethtool -K enp37s0 sg off # on a7 (internal network interface)

और मैंने i7 को भी फिर से शुरू किया (कई डॉकटर नेटवर्क इंटरफेस थे, वे अब चले गए हैं)

docker-ce अब हर जगह है 5:19.03.1~3-0~debian-buster

टूटे हुए निर्माण की सूचना तत्काल दें।

ऐसा लगता है कि master बिल्ड फिर से विफल हो गया है , क्योंकि v2-debian-buster से कनेक्शन की समस्या है (समस्या #2995 भी देखें)।

मैंने अपने व्यवस्थापक से a7/v2/i7 के बीच स्विच देखने के लिए कहा। मैंने अभी के लिए v2 और i7 को निष्क्रिय कर दिया है।

मैंने लिबेलेक्ट्रा/मास्टर और लिबेलेक्ट्रा-दैनिक को फिर से शुरू किया।

हमने सभी 3 पीसी के लिए पोर्ट बदल दिए हैं।

फिर मैंने v2/i7 पर jenkins homedir को हटा दिया और v2/i7 एजेंट को पुनरारंभ किया।

ऐसा लगता है कि v2-debian-buster पर और जगह उपलब्ध नहीं है :

ApplyLayer निकास स्थिति 1 stdout: stderr: /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o लिखें: डिवाइस पर कोई स्थान नहीं बचा है

.

रिपोर्टिंग के लिए धन्यवाद, मैंने v2 पर (बहुत अधिक) जगह बनाई है।

समाप्त कार्य निकालें:

फ़ाइल सिस्टम का आकार उपयोग किया गया उपयोग करें% माउंटेड का उपयोग करें
/dev/sda3 417G 227G 164G 58% /

माइग्रेशन के कारण बिल्डसर्वर डाउन हो गया है (ताकि हमें नए बिल्डसर्वर के बैकअप में लगातार स्थिति मिल सके)

https://build.libelektra.org/jenkins/ फिर से शुरू हो रहा है

बैकअप के दौरान कर्नेल त्रुटियों के कारण बिल्ड सर्वर पर लोड 200 था, सर्वर ने अब प्रतिक्रिया नहीं की और रीसेट करने की आवश्यकता थी।

लॉग संदेश थे (उदाहरण):

[87400.120008]  [<ffffffff810be6a8>] ? find_get_page+0x1a/0x5f

[87372.120005]  [<ffffffff81357f52>] ? system_call_fastpath+0x16/0x1b
[87372.120005] Code: f6 87 d1 04 00 00 01 0f 95 c0 c3 50 e8 d7 36 29 00 65 48 8b 3c 25 c0 b4 00 00 e8 d0 ff ff ff 83 f8 01 19 c0 f7 d0 83 e0 fc 5a c3 <48> 8d 4f 1c 8b 57 1c eb 02 89 c2 85 d2 74 16 8d 72 01 89 d0 f0
[87372.120005] Call Trace:
[87372.120005]  [<ffffffff810be6cc>] ? find_get_page+0x3e/0x5f
[87372.120005]  [<ffffffffa016962f>] ? lock_metapage+0xc2/0xc2 [jfs]

[87400.110012] BUG: soft lockup - CPU#0 stuck for 22s! [cp:15356]

उम्मीद है कि हम अगले सप्ताह की शुरुआत में जल्द ही प्रवास कर सकते हैं ( @Mistreated ?)

सर्वर वर्तमान में छापे का एक पुन: समन्वयन करता है, इसलिए उम्मीद करें कि यह बहुत धीमा होगा।

जेनकिंस बिल्ड अब और नहीं किए जाते हैं, देखें #3035

जेनकींस अब फिर से शुरू हो गया है। कृपया जेनकिंस निर्माण कार्य दोहराएं।

ऐसा लगता है कि v2-debian-buster ऑफ़लाइन है:

a7.complang.tuwien.ac.at:22221 पर SSH कनेक्शन खोलना।
कनेक्शन अस्वीकृत (कनेक्शन अस्वीकृत)

.

धन्यवाद, मैंने अपने व्यवस्थापक से संपर्क किया लेकिन मुझे डर है कि वह पहले ही कार्यालय से बाहर हो जाएगा।

हर्बर्ट ने कल ही v2 को फिर से शुरू कर दिया है। उन्होंने "एक साथ मल्टीथ्रेडिंग" को अक्षम कर दिया।

यदि कोई सर्वर (v2, i7, a7) फिर से क्रैश हो जाता है, तो कृपया "herbert atcomplang.tuwien.ac.at" के माध्यम से सीधे हमारे व्यवस्थापक से संपर्क करें। एकाधिक ईमेल से बचने के लिए कृपया यहां भी रिपोर्ट करें।

मुझे लगता है कि master शाखा के लिए v2-debian-buster पर गिट भंडार में कुछ गड़बड़ है :

git fetch --tags --progress https://github.com/ElektraInitiative/libelektra.git +refs/heads/master:refs/remotes/origin/master +refs/heads/*:refs/remotes/origin/* --prune" returned status code 128:
stdout: 
stderr: error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
fatal: loose object 9c0bc3ca6fcbc610abd845aeff5f666938d24117 (stored in .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117) is corrupt
fatal: the remote end hung up unexpectedly

. मैंने पहले ही तीन बार बिल्ड को पुनरारंभ किया है, लेकिन जेनकींस हमेशा एक ही त्रुटि के साथ विफल रहता है।

दुर्भाग्य से v2 में btrfs हैं जो कभी-कभी फाइलों को भ्रष्ट करने लगते हैं। इसी तरह की समस्या हमारे पास पहले से ही विफल docker pull । वर्तमान मामले में, फ़ाइल 0bc3ca6fcbc610abd845aeff5f666938d24117 दूषित लगती है। इस फ़ाइल की घटनाओं पर md5sum चलाते समय, मुझे मिलता है:

b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/libelektra/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
d41d8cd98f00b204e9800998ecf8427e  ./workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117

मैंने अब मास्टर के लिए पूरी निर्देशिका हटा दी है और बिल्ड को पुनरारंभ किया है। यह भी देखें #3054

चूंकि मैं अब कुछ दिनों के लिए उपलब्ध नहीं हूं, कृपया पहुंच से बाहर a7/i7/v2 के मुद्दों पर "complang.tuwien.ac.at पर हर्बर्ट" से संपर्क करें। @Misट्रीटेड हर उस चीज़ के लिए ज़िम्मेदार होगा जो

कृपया हमेशा यहां रिपोर्ट करें, ताकि एकाधिक ईमेल से बचा जा सके और ताकि सभी को इस बात की अच्छी जानकारी हो कि क्या हो रहा है।

क्या बिल्ड सर्वर में वर्तमान में खराबी है?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

क्या बिल्ड सर्वर में वर्तमान में खराबी है?

ऐसा लगता है कि मुख्य जेनकींस बिल्ड सर्वर कनेक्ट करने में असमर्थ है i7 । मैंने नोड को अस्थायी रूप से ऑफ़लाइन के रूप में चिह्नित किया है।

निर्माण मनमाने मामलों पर विफल रहता है:
यहाँ यह बिना किसी कारण के बाधित हो गया
यहां एक परीक्षण मामला विफल हो जाता है जो मेरे पीआर से असंबंधित है (मैंने अभी किसी भी कोड को छूने के लिए एक डिज़ाइन निर्णय जोड़ा है)

यहाँ यह बिना किसी कारण के बाधित हो गया

मुझे दो पीआर के लिए समान रुकावट कोड 143 मिला है और मैं अभी तक उन्हें समझा नहीं सकता। मैंने बिल्ड को फिर से शुरू किया और उम्मीद है कि यह अब काम करेगा।

यहां एक परीक्षण मामला विफल हो जाता है जो मेरे पीआर से संबंधित नहीं है

इसे #3103 के साथ @sanssecours को धन्यवाद देना चाहिए। कृपया मास्टर को रिबेस करें।

नया जेनकींस नोड hetzner-jenkins1 ठीक से काम नहीं कर रहा है । मैंने नोड को अस्थायी रूप से ऑफ़लाइन के रूप में चिह्नित किया है।

मैंने i7 पर docker को अपग्रेड किया और मशीन को पुनरारंभ किया। मुझे उम्मीद है कि इससे समस्या ठीक हो जाएगी। एजेंट फिर से ऑनलाइन है। कृपया यहां समस्याओं की रिपोर्ट करें (और/या एजेंट को निष्क्रिय करें)।

वर्तमान में #3065 का एक कार्य i7 पर चल रहा है।

@ गलत व्यवहार क्या आप कृपया हेट्ज़नर-जेनकिंस 1 डिबग कर सकते हैं?

क्या कुछ समय के लिए लिंक चेक को आसानी से बंद करने की संभावना है?

पूरे दिन यही होता रहा:

doc/tutorials/snippet-sharing-rest-service.md:63:0 http://cppcms.com/wikipp/en/page/apt
doc/tutorials/snippet-sharing-rest-service.md:158:0 http://cppcms.com/wikipp/en/page/cppcms_1x_config
doc/news/2016-12-17_website_release.md:94:0 http://cppcms.com
doc/tutorials/snippet-sharing-rest-service.md:62:0 http://cppcms.com/wikipp/en/page/cppcms_1x_build

अन्य पीआर (हाल ही में #3115, #3113) भी प्रभावित हुए हैं। डाउन फॉर एवरीवन या

अद्यतन: वेबसाइट अभी भी ऑफ़लाइन है। मैंने इसके लिए #3117 पीआर बनाया है।

क्या कुछ समय के लिए लिंक चेक को आसानी से बंद करने की संभावना है?

आप अलग-अलग लिंक को test/linkchecker.whitelist में जोड़कर बंद कर सकते हैं (जैसा कि आपको पहले ही पता चल गया है)

मैं साइरस से विफल बिल्ड को फिर से नहीं चला सकता। देखें https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

बटन कुछ नहीं करता है। क्या इसे काम करने के लिए कोई जादू की चाल है?

संपादित करें: या तो किसी ने कुछ बदल दिया या x`th कोशिश ने आखिरकार काम कर लिया। निर्माण फिर से चल रहा है! :)

ऐसा लगता है कि बिल्ड एजेंट a7-debian-buster पुन: लॉन्च करने में सक्षम नहीं है:

…
[10/28/19 06:02:59] [SSH] Starting slave process: cd "/home/jenkins" && java  -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.25
This is a Unix agent
Evacuated stdout

.

संपादित करें: या तो किसी ने कुछ बदल दिया या x`th कोशिश ने आखिरकार काम कर लिया। निर्माण फिर से चल रहा है! :)

आपकी टिप्पणी देखने के बाद मैंने "Restart Failed Build Jobs" बटन भी दबाया। जहां तक ​​​​मैं कह सकता हूं कि बटन दबाकर वास्तव में असफल निर्माण नौकरियों को पुनरारंभ किया गया था।

आपकी टिप्पणी देखने के बाद मैंने "Restart Failed Build Jobs" बटन भी दबाया। जहां तक ​​​​मैं कह सकता हूं कि बटन दबाकर वास्तव में असफल निर्माण नौकरियों को पुनरारंभ किया गया था।

हालांकि यह मेरे लिए काम नहीं किया, मैं अगली बार कुछ जीआईएफ प्रदान करूंगा!

मैं बिल्ड सर्वर और उसके नोड्स को पुनरारंभ करूँगा। #3121 और #3099 के निर्माण कार्य को फिर से शुरू करने की आवश्यकता है क्योंकि उनके पास मृत एजेंटों पर काम था।

हालांकि यह मेरे लिए काम नहीं किया, मैं अगली बार कुछ जीआईएफ प्रदान करूंगा!

आपको GIF प्रदान करने की आवश्यकता नहीं है, क्योंकि मुझे पहले से ही आप पर विश्वास है .

ऐसा लगता है कि जेनकिंस को रुकने में परेशानी होती है, मैं सभी जावा प्रक्रियाओं को जबरन मारने से पहले थोड़ा इंतजार करता हूं।

मैंने सभी एजेंटों पर डॉकटर को भी अपग्रेड किया (i7 पर इसे पहले ही अपग्रेड किया गया था)।

जेनकिंस फिर से दिल की धड़कन के अंतराल के साथ है जैसा कि #2984 में सुझाया गया है। सभी नोड्स जुड़े हुए हैं।

कृपया सभी कार्यों को आवश्यकतानुसार पुनः आरंभ करें और किसी भी समस्या की रिपोर्ट यहां करें।

v2 बंद है, मैंने अपने व्यवस्थापक से पुनः आरंभ करने के लिए कहा।

मैंने v2 को फिर से सक्षम किया, क्योंकि ऐसा लगता है कि यह ऊपर है और हमारा बिल्ड बैकलॉग पर्याप्त रूप से आकार में है।

क्या फिर से निर्माण में कोई समस्या है ( hetzner-jenkins1 )?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

क्या फिर से निर्माण में कोई समस्या है ( hetzner-jenkins1 )?

हाँ । मैंने नोड को निष्क्रिय कर दिया।

यह सिर्फ डिस्क कोटा पार हो गया, मैं इसे स्मृति से अधिक नहीं करना चाहता था। मैंने इसे अब साफ कर दिया। यह फिर से ऊपर है।

नोड अपडेट किया गया।

मैंने हेट्ज़नर-जेनकिंस 1 को 4 समानांतर बिल्ड में बढ़ाया। यह केवल एक अस्थायी उपाय है जब तक कि वहां और कुछ नहीं चल रहा है।

मैंने अस्थायी रूप से hetzner-jenkins1 पर निष्पादकों की संख्या को 4 से घटाकर 2 कर दिया, क्योंकि टेस्टसूट का समय समाप्त हो रहा है। मुझे लगता है कि ऐसा तब होता है जब परीक्षण चलने के दौरान बहुत सी नौकरियां संकलित हो रही हैं। हमें उपलब्ध संसाधनों को एक ही कंटेनर तक सीमित करने की आवश्यकता हो सकती है क्योंकि यह अन्य कार्यों में बहुत अधिक हस्तक्षेप नहीं करता है।

अगर आपको लगता है कि यह गलत तरीका था, तो इसे बेझिझक सुधारें।

संपादित करें: 1 से कम हो गया क्योंकि परीक्षण अभी भी समय समाप्त हो रहे हैं और लगातार अधिक संसाधनों को बर्बाद कर रहे हैं।

@mpranj इसे ठीक करने के लिए धन्यवाद!

@ गलत व्यवहार क्या आपने शायद केवल एक ही सीपीयू या समान असाइन किया था? क्या आप अधिक असाइन कर सकते हैं और निष्पादकों की संख्या को अधिक बढ़ा सकते हैं? हार्डवेयर को v2 की तरह मजबूत होना चाहिए।

मैंने i7-debian-buster अक्षम कर दिया क्योंकि कोई डिस्क स्थान नहीं बचा है जिससे सभी बिल्ड विफल हो जाते हैं। अगर किसी के पास पहुंच है तो कृपया कुछ साफ करें और इसे फिर से सक्षम करें।

@mpranj अक्षम करने के लिए धन्यवाद!

क्षमा करें, जहां मैं वर्तमान में हूं, वहां ssh अवरुद्ध है (कुछ एप्लिकेशन फ़ायरवॉल, अन्य पोर्ट पर ssh भी काम नहीं करता है)। इसलिए मैं अभी एक्सेस नहीं दे सकता या कोई सफाई नहीं कर सकता।

जैसा कि i7 एजेंटों में सबसे कमजोर है, वैसे भी यह कोई बड़ी बात नहीं हो सकती है।

@ क्या आपने शायद केवल एक ही सीपीयू या समान असाइन किया है? क्या आप अधिक असाइन कर सकते हैं और निष्पादकों की संख्या को अधिक बढ़ा सकते हैं? हार्डवेयर को v2 की तरह मजबूत होना चाहिए।

मुझे नहीं पता कि v2 कितना मजबूत है।
वर्तमान में jenkins1 8 मेमोरी और 16 स्वैप के साथ 4 CPU का उपयोग करता है। मैं इसे आसानी से बढ़ा सकता हूं, मुझे नहीं पता कि आप इसे किस बिंदु तक बढ़ाना चाहते हैं।

भविष्य के हार्डवेयर निर्णयों के लिए एक नोट: फ़ोरोनिक्स अपने सीपीयू लेखों में संकलन परीक्षण करता है (उदाहरण के लिए Ryzen 7 3700X, Ryzen 9 3900X परीक्षण, लेख के निचले सिरे की ओर )।

ऐसा लगता है कि हेट्ज़नर ने हाल ही में AMD Ryzen 7 3700X को अपने AMD आधारित सर्वर में जोड़ा है।

मुझे नहीं पता कि v2 कितना मजबूत है।

@ingwinlu ने इस बारे में अपनी थीसिस में लिखा था (अबगाबेन रेपो lukas_winkler में पाया जाना)

वर्तमान में jenkins1 8 मेमोरी और 16 स्वैप के साथ 4 CPU का उपयोग करता है। मैं इसे आसानी से बढ़ा सकता हूं, मुझे नहीं पता कि आप इसे किस बिंदु तक बढ़ाना चाहते हैं।

जब तक हमारे पास सर्वर पर कुछ और नहीं चल रहा है तब तक आप सभी संसाधन आवंटित कर सकते हैं। बाद में हम अभी भी नीचे जा सकते हैं (जब हम जेनकिंस को स्थानांतरित करते हैं)।

मैंने हेट्ज़नर-जेनकिंस1.
फ्रंटएंड के साथ त्रुटि जहां यह स्मृति से बाहर हो जाती है उसे ठीक किया जाता है।
अब यह 2 समानांतर बिल्ड चलाता है।

ऐसा लगता है कि v2-debian-buster पर कोई जगह नहीं बची है :

validation.cpp:69:1: fatal error: error writing to /tmp/cccJFleY.s: No space left on device

.

धन्यवाद, मैंने इसे ऑफ़लाइन भी चिह्नित किया है, जब तक कि किसी के पास इसे साफ़ करने की पहुंच न हो।

hetzner-jenkins1 मेरे 3 पीआर विफल हो गए क्योंकि डिस्क कोटा पार हो गया है। यहाँ आउटपुट पर है:

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on hetzner-jenkins1
/home/jenkins/workspace/libelektra_PR-3106-LB35J55FSRLFKFEU2WP6AWVLM3IH4JWI6C5B57NWB6DDARN4JDUA@tmp/ff803792-a127-4b8f-8588-439af982c8a4: Disk quota exceeded

hetzner-jenkins1 को ऑफ़लाइन के रूप में चिह्नित किया गया क्योंकि डिस्क कोटा पार हो गया था।

मैंने i7 और v2 को साफ़ किया ( /home/jenkins/workspace/* को हटाकर और docker system prune चलाकर)। अब हमारे पास है:

• i7: /dev/mapper/i7--vg-home 199G 152G 37G 81% /home
• v2: /dev/sda3 417G 255G 147G 64% /

फिर मैंने एजेंटों को पुनरारंभ किया।

@Misट्रीटेड क्या आप कृपया #3160 को ठीक कर सकते हैं ताकि यह इतनी तेजी से दोबारा न हो। कृपया हेट्ज़नर-जेनकिंस1 को भी ठीक करें। इस मशीन पर बहुत सारे संसाधन हैं यह वास्तव में जरूरी नहीं है कि यह हर दिन संसाधन सीमा को हिट करे।

मुझे नहीं पता कि डिस्क का आकार बदलने का कोई अच्छा तरीका है या नहीं। यही कारण है कि मैं एक ही बार में सब कुछ नोड नहीं दे रहा हूं .. हेट्ज़नर फिर से ऊपर है।

v2 फिर से जगह से बाहर था, मैंने साफ किया: /dev/sda3 417G 315G 102G 76% /

@ गलत व्यवहार https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log प्रारंभ नहीं होता है

मुझे लगता है कि बिल्ड सिस्टम वर्तमान में पूरी तरह से अटका हुआ है, पीआर नहीं बनाए जा रहे हैं।

रिपोर्ट करने के लिए धन्यवाद, मैं जेनकिंस को फिर से शुरू करूंगा और डिस्क के भर जाने पर कुछ फाइलों को साफ कर दूंगा।

@ गलत व्यवहार https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log प्रारंभ नहीं होता है

एजेंट सफलतापूर्वक जुड़ा और ऑनलाइन

मुझे लगता है कि अब सब कुछ ठीक है hetnzer-jenkins1 के साथ?

बहुत - बहुत धन्यवाद! ऐसा लगता है कि जेनकींस अभी भी बिल्ड पर प्रतिक्रिया नहीं दे रहा है। v2 और i7 अब दोनों विफल हो जाते हैं: java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave ।

जेनकिंस फिर से सक्रिय हैं, कृपया कार्य पुनः आरंभ करें।

java.io.IOException: गुलाम पर '/home/jenkins' में गुलाम की नकल नहीं कर सका।

फिक्स्ड (अंतरिक्ष से बाहर भी था)

@Mistreated कृपया

@Mistrained "जेनकींस लिबेलेक्ट्रा कृपया" अभी भी टूटा हुआ है, क्या यह वेबहुक के परिवर्तनों से संबंधित है?

हो सकता है कि आज ही नए जेनकींस में बदलने की कोशिश करें, लेकिन अगर आप इसे करने में सक्षम नहीं हैं, तो कृपया पुराने इंस्टेंस को फिर से काम करें!

मैंने एक रिपोजिटरी स्कैन ट्रिगर किया, अब "जेनकींस बिल्ड लिबेलेक्ट्रा कृपया" फिर से काम करने लगते हैं।

ऐसा लगता है कि डिस्क v2-debian-buster लिए भरी हुई है

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

दुर्भाग्य से। मैंने v2 को तब तक ऑफ़लाइन के रूप में चिह्नित किया जब तक कि इसका समाधान नहीं हो जाता।

रिपोर्टिंग के लिए धन्यवाद!

@mpranj मैंने आपको एक्सेस दिया है, क्या आप कृपया सफाई करने का प्रयास कर सकते हैं?

शुक्रिया! मुझे ऐसा लगता है कि डॉकर पुरानी छवियों के आस-पास पड़ी हुई संसाधनों की एक बहुतायत है। इसके अतिरिक्त ऐसा लगता है कि btrfs + docker छोटी गाड़ी हैं। डॉकर प्रत्येक कंटेनर के लिए btrfs सबवॉल्यूम बनाता है और बाद में इसे ठीक से साफ नहीं करता है। docker system prune -f कमांड भी जगह खाली नहीं करता है।

मैंने संसाधनों को मुक्त करने और btrfs को संतुलित करने के लिए रखरखाव के लिए v2 और a7 नीचे ले लिया।

डोकर लॉगिन विफल

डोकर छवियों को खींच नहीं सकता। डोकर हब के साथ कुछ हो रहा है?

हाँ, क्षमा करें, a7 मैंने डॉकर हब भी हटा लिया। जब यह फिर से शुरू होगा तो मैं यहां एक संदेश पोस्ट करूंगा।

a7 डोकर हब सहित फिर से ऊपर है। मैंने v2 ऑफ़लाइन छोड़ दिया क्योंकि यह छवियों को खींचने के लिए हब में प्रवेश नहीं कर सकता है?!? मुझे नहीं पता कि वहां क्या गलत है, मैंने कोई क्रेडेंशियल नहीं बदला है और अन्य नोड्स लॉगिन कर सकते हैं। कोई विचार?

Btrfs अभी भी पृष्ठभूमि में संतुलन बना रहा है, a7 एक या दो घंटे के लिए धीमा हो सकता है।

@mpranj इसे ठीक करने के लिए धन्यवाद! btrfs री-बैलेंसिंग के लिए किन कमांड्स की जरूरत थी?

दुर्भाग्य से, मैं क्रेडेंशियल नहीं जानता, मुझे उम्मीद है कि @ingwinlu हमारी मदद कर सकता है।

जिन आदेशों का मैं पुन: संतुलन करता था वे थे:

Btrfs के साथ शायद-बग ठीक करें:

btrfs balance start -dusage=0 -musage=0 /mountpoint

वास्तव में fs को फिर से संतुलित करें, इसमें लंबा समय लगता है। उपयोग पैरामीटर को ट्यून किया जा सकता है / किया जाना चाहिए, यह वही है जो आज काम करता है:

btrfs balance start -dusage=80 /

क्रेडेंशियल्स को आसानी से बदला जा सकता है, लेकिन हमें उन सभी जेनकिंस एजेंटों में लॉग इन करना होगा जो नए क्रेडेंशियल्स के साथ फिर से डॉकर हब से जुड़ते हैं।

बड़ी समस्या यह थी कि कुछ डॉकटर कंटेनर अभी भी चल रहे थे और डॉकर सिस्टम प्रून ज्यादा कुछ नहीं कर रहा था। इसलिए मैंने एजेंटों को नीचे ले लिया और नीचे होने पर सब कुछ मुक्त कर दिया। कंटेनर के टन बस आसपास पड़े थे।

हां, दुर्भाग्य से कंटेनरों को जल्दी से फिर से बनाया जाता है। मुझे आशा है कि @Mistreated परिवाद-दैनिक कार्य को शीघ्र ही ठीक कर सकता है (यह docker system prune निष्पादित करता है)।

मैंने कुछ काफी शामिल डिजिटल फोरेंसिक भी किए और हब क्रेडेंशियल्स को चुरा लिया। :हस रहा:

v2 फिर से चल रहा है।

बहुत - बहुत धन्यवाद! :100: कृपया हमें क्रेडेंशियल भेजें।

भेज दिया। बीटीडब्ल्यू मुझे लगता है कि a7 शायद केवल खराब डिस्क गति के कारण धीमा है, लेकिन यह अच्छा है कि इसमें डॉकर हब के लिए पर्याप्त जगह है। ऐसा लगता है कि सीपीयू ज्यादातर समय वहां कुछ नहीं कर रहा है।

एक और विचार: हो सकता है कि हम अब जैसी स्थितियों से बचने के लिए प्रति क्रोनजॉब के लिए महत्वपूर्ण सफाई कार्य भी कर सकें।

कृपया हमें क्रेडेंशियल भेजें।

@mpranj मुझे लगता है कि मैं "हम" के इस समूह में था। मैं कुछ सीसी या ऐसा कुछ में नहीं था?

@ गलत व्यवहार क्षमा करें, मैंने इसे a7 आपको CREDENTIALS.txt अपने होमडायर में मिलेगा।

मुझे नए जेनकींस-सर्वर का परीक्षण करने के लिए हेट्ज़नर-जेनकिंस1 नोड की आवश्यकता है। मैं इसे कल सुबह तक पुराने सर्वर पर बंद कर दूंगा।

आप परीक्षण के लिए आसानी से दूसरा hetzner-jenkins2 बना सकते हैं। यदि यह केवल इस रात के लिए है, तो यह ठीक होना चाहिए।

एक और विचार: हो सकता है कि हम अब जैसी स्थितियों से बचने के लिए प्रति क्रोनजॉब के लिए महत्वपूर्ण सफाई कार्य भी कर सकें।

libelektra-दैनिक यह सफाई कार्य करता है लेकिन यह अब विफल हो जाता है: #3160. यदि आपके पास इस नौकरी को बेहतर बनाने के विचार हैं, तो कृपया हमें बताएं।

मुझे लगता है कि मैं "हम" के इस समूह में था। मैं कुछ सीसी या ऐसा कुछ में नहीं था?

हां, माफ करना मैं एमपीरांज को बताना भूल गया था कि "हम" आपको संदर्भित करता है।

मुझे आशा है कि यह ठीक है कि मैं थोड़ी देर के लिए hetzner-jenkins1 रखता हूं, अब सभी बिल्ड अच्छे हैं मुझे लगता है कि मैं आज रात सर्वर को पूरी तरह से चालू कर सकता हूं।

v2 पहुंच से बाहर है, मैंने व्यवस्थापक से संपर्क किया।

मुझे आशा है कि यह ठीक है कि मैं थोड़ी देर के लिए hetzner-jenkins1 रखता हूं, अब सभी बिल्ड अच्छे हैं, मुझे लगता है कि मैं आज रात सर्वर को पूरी तरह से चालू कर सकता हूं।

यह बहुत अच्छा होगा!

v2 पहुंच योग्य नहीं है, मैंने व्यवस्थापक से संपर्क किया।

धन्यवाद लेकिन मुझे डर है कि वह सोमवार से पहले जवाब नहीं देगा।

v2 को एक नया कर्नेल मिलता है (यह अभी दुर्घटनाग्रस्त हो गया)।

i7 को भी पुनरारंभ किया जाएगा।

सभी 3 सर्वर (v2, a7, i7) में अब "Linux v2 5.2.0-0.bpo.2-amd64 #1 SMP डेबियन 5.2.9-2~bpo10+1 (2019-08-25) x86_64 GNU/Linux है। "

वे तैयार हैं और ऑनलाइन हैं, यदि आवश्यक हो तो कृपया कार्य पुनः आरंभ करें।

सिर्फ एक नोट:
मैंने नए सर्वर के साथ फिर से रेपो स्कैन किया। यह पुराने पर कुछ त्रुटियाँ कर सकता है..

ऐसा लगता है कि मास्टर [1] भी नए सर्वर पर बनाया गया था। यह सफलतापूर्वक नहीं था। स्थिति पर क्लिक करने पर, एक लॉगिन पृष्ठ दिखाई देता है [2]। कृपया जेनकिंस को पुन: कॉन्फ़िगर करें कि सब कुछ लॉग इन किए बिना देखा जा सकता है।

उम्मीद है कि हम जल्द ही नए जेनकींस पर स्विच कर सकते हैं। दो अलग-अलग जेनकींस से त्रुटियों को देखने से स्थिति आसान नहीं होती है: पलक:

[1] https://github.com/ElektraInitiative/libelektra/commits/master#
[2] http://95.217.75.163 :8080/login?from=%2Fjob%2Flibelektra%2Fjob%2Fmaster%2F1%2Fdisplay%2Fredirect

@markus2330 क्या अपग्रेड के बाद a7/v2 को दूरस्थ रूप से रीबूट किया जा सकता है या कुछ नुकसान हैं?

आमतौर पर यह काम करता है लेकिन अगर यह जरूरी नहीं है तो बेहतर है कि एडमिन के आने तक इंतजार किया जाए। अगर यह आपके लिए ठीक है तो मैं मंगलवार को फिर से चालू कर सकता हूँ?

शुक्रिया! कुछ भी जरूरी नहीं, सिर्फ एक सामान्य प्रश्न। यह सामने आया क्योंकि डेबियन 10.2 अभी जारी किया गया था। मैं उन्नयन के साथ थोड़ा इंतजार करूंगा।

आप फिर भी अपग्रेड कर सकते हैं (केवल रिबूट के बिना)। फिर, एक दुर्घटना के मामले में, हमारे पास पहले से ही 10.2 कर्नेल होगा जब व्यवस्थापक रीसेट बटन दबाएगा: पलक:

@mpranj क्या आप शायद एक शुद्ध करता है? या यह डॉकटर को रोके बिना संभव नहीं है?

https://docs.docker.com/storage/storagedriver/btrfs-driver/ क्रोनजॉब में btrnfs को रीबैलेंस करने की भी सिफारिश करता है।

क्या आप शायद एक क्रोनजॉब जोड़ सकते हैं जो पुराने स्नैपशॉट को शुद्ध करता है? या यह डॉकटर को रोके बिना संभव नहीं है?

मैं सभी डॉकटर कंटेनरों को रोके बिना क्रोनजॉब जोड़ सकता हूं। यह सब कुछ साफ नहीं कर सकता है, लेकिन हम इसे आजमा सकते हैं। जैसा मैंने कहा, कभी-कभी कंटेनर हमेशा के लिए चलते रहते हैं/मशीन के दुर्घटनाग्रस्त होने तक। पूर्ण सफाई के लिए हमें बिल्ड एजेंट को अस्थायी रूप से अक्षम करने की आवश्यकता होती है, फिर हम सभी कंटेनरों को बलपूर्वक रोक सकते हैं।

मैं क्रोनजॉब के रूप में रीबैलेंस भी जोड़ सकता हूं।

धन्यवाद, आइए इसे आजमाते हैं।

मास्टर स्मृति से बाहर है। मैं पुराने जेनकींस पर स्कैन रिपोजिटरी चलाने के लिए चाहता था क्योंकि ए 7 और आई 7 को डॉकर छवियों को खींचने में निम्न त्रुटि मिलती है:

डोकर लॉगिन विफल

मुझे अब नए सर्वर पर v2 और hetzner-jenkins1 चल रहा है।

मास्टर स्मृति से बाहर है।

रिपोर्टिंग के लिए धन्यवाद। मैंने कुछ पुराने कवरेज डेटा को हटा दिया और मास्टर नोड को फिर से सक्षम किया। खुले पुल अनुरोध वाले सभी लोगों के लिए: कृपया jenkins build libelektra please साथ अपने जेनकींस बिल्ड को फिर से शुरू करें। असुविधा के लिए खेद है।

#3234 में @raphi011 ने सुझाव दिया:

आईएमओ यह वास्तव में जरूरी है, परीक्षणों की चंचलता और धीमापन किसी भी बदलाव को करना असंभव नहीं तो मुश्किल बना देता है अगर आपको उन्हें सत्यापित करने के लिए इतना लंबा इंतजार करना पड़ता है।

मैं मानता हूं कि यह वास्तव में जरूरी है लेकिन @Mistreated पहले से ही वह कर रहा है जो वह कर सकता है।

तो शायद हम बिल्ड सर्वर का अधिक संयम से उपयोग कर सकते हैं और केवल तभी निर्माण कर सकते हैं जब हमें वास्तव में लगता है कि पीआर को जल्द ही विलय किया जाना है। अनावश्यक निर्माणों को निरस्त किया जाए।

या (अस्थायी रूप से) परिवर्तनों को आगे बढ़ाने पर पीआर के स्वचालित निर्माण को रोकने के बारे में क्या है (इसलिए निर्माण केवल jenkins build libelektra please शुरू होता है)? @ क्या आप जानते हैं कि ऐसा करने के लिए जेनकिंस को फिर से कैसे कॉन्फ़िगर करना है (मुझे विकल्प नहीं मिला)?

मुझे यह भी लग रहा है कि jenkins build libelektra please इस समय काम नहीं करता है, कम से कम यह इस निर्माण के लिए काम नहीं करता है: https://github.com/ElektraInitiative/libelektra/pull/3073 मुझे एक धक्का देना पड़ा पाइपलाइन शुरू करने के लिए खाली प्रतिबद्धता।

क्लीनअप क्रोनजॉब लागू किया गया और बैकपोर्ट कर्नेल को a7 और v2 पर अपग्रेड किया गया। कर्नेल के लिए काफी चेंजलॉग है, यह अगले रिबूट पर सक्रिय होगा।

आपका बहुत बहुत धन्यवाद! क्या "पुराना" बैकपोर्ट कर्नेल अभी भी स्थापित है ताकि बूट न ​​होने पर हमारे पास फ़ॉलबैक हो?

हाँ, इसे नए कर्नेल में सफल बूट के बाद हटाया जा सकता है।

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on i7-debian-buster

docker login failed

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3244/1/pipeline

मैंने मैन्युअल सफाई, कर्नेल और डॉकर अपग्रेड के लिए i7 अक्षम कर दिया है। जब मैं इस पर काम कर रहा था तब किसी ने i7 को सक्षम किया। सब कुछ फिर से चल रहा है।

@Piankero मैंने अब आपके निर्माण को फिर से शुरू किया है।

मुझे यह भी लग रहा है कि jenkins build libelektra please इस समय काम नहीं करता है, कम से कम यह इस निर्माण के लिए काम नहीं करता है: # 3073 मुझे पाइपलाइन शुरू करने के लिए एक खाली प्रतिबद्धता को धक्का देना पड़ा।

अभी काम करता है

@ क्या आप जानते हैं कि ऐसा करने के लिए जेनकिंस को फिर से कैसे कॉन्फ़िगर करना है (मुझे विकल्प नहीं मिला)?

मैंने जेनकींस कॉन्फ़िगरेशन में निम्नलिखित जोड़ा:

स्वचालित SCM ट्रिगरिंग को रोकें

सभी के लिए ध्यान दें: "जेनकींस बिल्ड लिबेलेक्ट्रा प्लीज" का उपयोग अब अनिवार्य है, बिल्ड जॉब केवल धक्का देने से शुरू नहीं होता है। जब हम इस सेटिंग को वापस करेंगे तो हम यहां सूचित करेंगे।

@दुर्व्यवहार किया धन्यवाद! आइए देखें कि क्या यह पर्याप्त है। मुझे आशा है कि मास्टर को धक्का अभी भी मास्टर बिल्ड को ट्रिगर करता है?

फिर भी, हेट्ज़नर नोड का होना बहुत अच्छा होगा। यदि एक ही समय में दो बिल्ड सर्वर द्वारा नोड का उपयोग किया जाता है तो क्या कोई समस्या है? या यदि यह एक समस्या है: क्या केवल सीटी का क्लोन बनाना बहुत आसान नहीं है?

@दुर्व्यवहार किया धन्यवाद! आइए देखें कि क्या यह पर्याप्त है। मुझे आशा है कि मास्टर को धक्का अभी भी मास्टर बिल्ड को ट्रिगर करता है?

मास्टर शाखा अब निम्नलिखित नियम का अपवाद है:

स्वचालित SCM ट्रिगरिंग को रोकें

से संबंधित

फिर भी, हेट्ज़नर नोड का होना बहुत अच्छा होगा। यदि एक ही समय में दो बिल्ड सर्वर द्वारा नोड का उपयोग किया जाता है तो क्या कोई समस्या है? या यदि यह एक समस्या है: क्या केवल सीटी का क्लोन बनाना बहुत आसान नहीं है?

मैंने एक नया CT (hetzner-jenkinsNode3) जोड़ा।

रेपो का क्लोन नहीं बना सका: https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

शायद इसका नए नोड से कुछ लेना-देना है? (ऐसे ही अनुमान लगाना)

शायद इसका नए नोड से कुछ लेना-देना है? (ऐसे ही अनुमान लगाना)

यह त्रुटि a7 . पर है

यह त्रुटि a7 . पर है

बहुत .. पुनः प्रयास करें?

बहुत .. पुनः प्रयास करें?

हाँ, मुझे नहीं लगता कि यह फिर से होगा..

मैं इसे आपके लिए फिर से चलाऊंगा।

@Mistrained मुझे लगता है कि हम फिर से स्वचालित निर्माण शुरू कर सकते हैं। लेकिन कृपया पहले #3160 देखें।

कोई विचार क्यों यह असफल होगा?

go: github.com/google/[email protected]: Get https://proxy.golang.org/github.com/google/uuid/@v/v1.1.1.mod: net/http: TLS handshake timeout

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2827/8/pipeline/648

कोई विचार क्यों यह असफल होगा?

ऐसा लगता है कि यह एक अस्थायी समस्या थी, यूआरएल वर्तमान में बिल्ड एजेंटों से पहुंचा जा सकता है।

लंबे समय में, डॉकर छवियों में इस तरह की निर्भरता को स्थापित करना बहुत अच्छा होगा, ताकि प्रत्येक बिल्ड के लिए उन्हें बार-बार डाउनलोड करने से बचा जा सके। जैसा कि आपने ऊपर उल्लेख किया है, अस्थायी रूप से अनुपलब्ध पैकेजों के कारण बिल्ड विफलताओं को भी रोकना चाहिए।

अच्छा तो.. jenkins build libelektra please तीसरा

हां, इस कारण से हमारे पास सीधे डॉकर छवियों में सभी निर्भरताएं हैं। मैंने बनाया #3251

मैंने रिबूट करने के लिए v2 और a7 ऑफ़लाइन लिया।

@markus2330 यदि आपको मौका मिले, तो a7 पर हाइपरथ्रेडिंग सक्षम करें।

v2 फिर से ऊपर है, a7 पर अभी भी एक बिल्डजॉब है।

मैंने नोड्स लिए और उन्हें नए सर्वर में जोड़ा। मैं इसे रात भर चलने दूंगा। यदि नए जेनकींस सर्वर पर और त्रुटियां हैं तो कल मैं नोड्स वापस कर दूंगा।

hetzner-jenkinsNode3 अभी भी पुराने जेनकींस पर चलेगा।

यदि नए जेनकींस सर्वर पर और त्रुटियां हैं तो कल मैं नोड्स वापस कर दूंगा।

छोटी बिल्ड त्रुटियां वापस स्विच करने का कारण नहीं हैं। किसी बिंदु पर हमें त्रुटियों को ठीक करने की आवश्यकता होती है, आगे और पीछे जाने में बहुत समय लगता है।

हालाँकि, शो-स्टॉपर जो हो सकता है, वह यह है कि नया सर्वर उपलब्ध नहीं है। (न
http://95.217.75.163:8066 और न ही ssh)। मैंने पावर बटन दबाया, देखते हैं कि मशीन फिर से चालू होती है या नहीं। हालांकि, हमें जांच करनी चाहिए कि समस्या क्या थी।

http://95.217.75.163 :8066

यदि समय है, तो कृपया लेटसेनक्रिप्ट का उपयोग करके टीएलएस को सक्षम करें, ताकि हम क्रेडेंशियल्स को लीक न करें और खुद को विभिन्न अन्य समस्याओं के लिए उजागर न करें?

इनपुट के लिए धन्यवाद! मेरा सुझाव है कि जब हम build.libelektra.org स्विच करते हैं तो हम इसे तुरंत करते हैं। नहीं तो हमारे पास दोहरा प्रयास है।

क्या यह त्रुटि ज्ञात है? Caught the following exception: null

ऐसा लगता है कि फ़ॉर्मेटिंग जांच विफल हो गई और अन्य बिल्ड समाप्त कर दिए गए।

आप ठीक कह रहे हैं। हालांकि एक भद्दा त्रुटि संदेश क्या है: पी

@ क्या आप कृपया फिर से सक्रिय कर सकते हैं कि

@ क्या आप कृपया फिर से सक्रिय कर सकते हैं कि

किया हुआ।

मैं नए सर्वर के लिए फिर से hetzner-jenkins1 और v2 उधार लेने वाला हूं।

आपको इसे वापस देने की आवश्यकता नहीं है, मुझे आशा है कि हम आज स्विच कर सकते हैं।

युक्ति: इस प्रकार के स्विच करते समय, DNS प्रविष्टि के TTL को कुछ असामान्य रूप से कम करना अच्छा होता है (उदाहरण के लिए build.libelektra.org के लिए वर्तमान में 21599 के बजाय 60)। परिवर्तन के प्रचार के बाद इसे हमें घंटों के बजाय एक मिनट के भीतर DNS प्रविष्टि को स्विच करने देना चाहिए। यदि बहुत देर हो चुकी है तो यह Google और opendns के DNS कैश को साफ़ करने में मदद कर सकता है, लेकिन कुछ लोग अनिवार्य रूप से पुराने संसाधन को तब तक देखेंगे जब तक कैश की गई प्रविष्टियाँ विश्व स्तर पर समाप्त नहीं हो जातीं।

संपादित करें: परिवर्तन के बाद डीएनएस पर कम भार डालने के लिए टीटीएल को स्पष्ट रूप से कुछ समझदार मूल्य पर वापस कर दिया जाना चाहिए।

हालांकि अब शायद बहुत देर हो चुकी है, मैंने $TTL 3600 स्विच किया (यदि हमें सब कुछ काम करने तक कई बदलावों की आवश्यकता है)।

www-new और build-new पहले से ही नए सर्वर की ओर इशारा करते हुए मौजूद है।

मैंने अब doc.libelektra.org स्विच किया है। @Misट्रीटेड प्रकाशन को ठीक कर देगा। मैं www-new.libelektra.org में देखूंगा

https://build-new.libelektra.org/ और https://www-new.libelektra.org/home को अभी काम करना चाहिए।

मैं अब सभी DNS प्रविष्टियों को बदल दूँगा।

सभी डीएनएस प्रविष्टियां बदली जाती हैं।

दुर्भाग्य से, सर्टिफिकेट विफल हो जाता है क्योंकि ऐसा लगता है कि यह पुराने सर्वर से बात कर रहा है लेकिन ऐसा लगता है कि यह केवल डाउनलोड और समुदाय (कम इस्तेमाल किए गए यूआरएल) को प्रभावित करता है।

तो उम्मीद है, सप्ताहांत के दौरान/बाद में सभी को अद्यतन DNS नाम दिखाई देंगे।

@Mistreated कृपया सभी कलाकृतियों के प्रकाशन को अपडेट करें: वेबसाइट के लिए भी। कृपया यह सुनिश्चित करने के लिए एक पीआर बनाएं कि सब कुछ ठीक से काम कर रहा है।

पुराना बिल्ड सर्वर अब बंद हो गया है।

मुझे नया सर्वर पुनः आरंभ करने की आवश्यकता है (नया कर्नेल और नेटवर्क ब्रिज जोड़ा गया)।

सर्वर फिर से Linux pve 5.0.21-5-pve के साथ काम कर रहा है।

मैंने सभी पीआर का पुन: स्कैन निर्धारित किया है।

pve में गलत कॉन्फ़िगरेशन/बग के कारण सर्वर ऑफ़लाइन (/etc/network/interfaces GUI द्वारा हटा दिया गया था?)।

बग यह था कि नेटवर्क उपकरणों का नाम बदलना (जो जीयूआई में मेरी कार्रवाई के कारण हुआ था) कर्नेल ओओपीएस की ओर जाता है:

Nov 23 21:32:08 pve kernel: [ 1682.138250] veth4d0199f: renamed from eth0
Nov 23 21:32:19 pve kernel: [ 1693.378374]  __x64_sys_newlstat+0x16/0x20
Nov 23 21:32:19 pve kernel: [ 1693.378380] Code: Bad RIP value.
Nov 23 21:32:19 pve kernel: [ 1693.378382] RDX: 00007fa58b238e20 RSI: 00007fa58b238e20 RDI: 00007fa58ba50d24
Nov 23 21:32:19 pve kernel: [ 1693.378383] R13: 0000000000000294 R14: 00007fa58ba50cc8 R15: 00007ffe65c2b158
Nov 23 21:34:20 pve kernel: [ 1814.210370]  request_wait_answer+0x133/0x210
Nov 23 21:34:20 pve kernel: [ 1814.210374]  fuse_simple_request+0xdd/0x1a0
Nov 23 21:34:20 pve kernel: [ 1814.210378]  ? fuse_permission+0xcf/0x150
Nov 23 21:34:20 pve kernel: [ 1814.210381]  path_lookupat.isra.47+0x6d/0x220
Nov 23 21:34:20 pve kernel: [ 1814.210385]  ? strncpy_from_user+0x57/0x1c0
Nov 23 21:34:20 pve kernel: [ 1814.210388]  __do_sys_newlstat+0x3d/0x70
Nov 23 21:34:20 pve kernel: [ 1814.210392]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

सर्वर फिर से चालू और चालू होना चाहिए।

पिछली समस्याएं बनी हुई हैं, हालांकि (वाक्यांश #3268 काम नहीं कर रहा है)

@ मिस्ट्रेड मास्टर भी अब स्वचालित रूप से निर्माण नहीं कर रहा है, मैं इसे अब मैन्युअल रूप से ट्रिगर करता हूं।

मैं #3268 में अत्यावश्यक त्रुटियाँ एकत्रित कर रहा हूँ। यह अच्छा होगा यदि आप यह भी जांच सकते हैं कि क्या सब कुछ doc/BUILDSERVER.md में वर्णित अनुसार काम करता है।

जेनकींस बिना किसी कारण के निर्माण नहीं करता है:
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

एक और निर्माण त्रुटि: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-2827/13/pipeline

रिपोर्टिंग के लिए धन्यवाद!

जैसा कि पहले ही कई बार चर्चा की जा

hetzner-jenkins1 : डिस्क कोटा पार हो गया

जैसा कि पहले ही कई बार चर्चा की जा

आज ही करूँगा

hetzner-jenkins1: डिस्क कोटा पार हो गया

@mpranj मैंने एक बिल्ड एजेंट के रूप में नया VM जोड़ा, जबकि hetzner-jenkins1 नीचे है।

मैंने docker system prune -a चलाकर hetzner-jenkins1 पर कुछ स्थान साफ़ किया और इसे फिर से सक्षम किया।

ऐसा लगता है कि फिर से एक समस्या है कि बहुत सारी चीज़ें docker system prune -f द्वारा साफ़ नहीं की जाती हैं। इस बार स्टोरेज ड्राइवर btrfs बल्कि vfs । :अस्पष्ट:

मैंने नए VM को बिल्ड एजेंट के रूप में जोड़ा, जबकि hetzner-jenkins1 नीचे है।

अब विचार यह है कि हम अब कंटेनर का उपयोग नहीं करते हैं बल्कि इसके बजाय केवल VM का उपयोग करते हैं।

मैंने docker system prune -a चलाकर hetzner-jenkins1 पर कुछ जगह साफ की और इसे फिर से सक्षम किया।

आपका बहुत बहुत धन्यवाद! क्या आप वहां क्रोनजॉब भी बना सकते हैं? (वीएम पर, कंटेनर पर नहीं)।

वहाँ एक क्रोनजॉब बनाओ?

किया हुआ।

जैसा कि पहले ही कई बार चर्चा की जा

अगर हमें नागिनेटर प्लगइन चाहिए तो हमें पाइपलाइन से फ्रीस्टाइल जॉब की ओर बढ़ना होगा। मैं विकल्पों की तलाश करूंगा।

VM पर बनाता है jenkinsNode3VM वर्तमान में विफल। वे डॉकर पुल करने में असमर्थ हैं:

unexpected EOF
script returned exit code 1

मैंने इसे अभी के लिए अक्षम कर दिया है जब तक कि कोई समस्या को ठीक नहीं कर सकता।

[क्रोनजॉब] हो गया।

शुक्रिया!

अगर हमें नागिनेटर प्लगइन चाहिए तो हमें पाइपलाइन से फ्रीस्टाइल जॉब की ओर बढ़ना होगा। मैं विकल्पों की तलाश करूंगा।

हाँ अच्छा उपाए। हो सकता है कि इसे हमारे जेनकिंसफाइल में कोड करना सबसे अच्छा हो। इसलिए यदि कोई समस्याग्रस्त बिल्ड जॉब/स्टेज विफल हो जाता है, तो इसका पुन: प्रयास किया जाता है। इन डॉकटर पुलों को कम से कम दो बार आजमाया जाता है क्योंकि यह सबसे लगातार होने वाली समस्याओं में से एक है।

VM पर बनाता है jenkinsNode3VM वर्तमान में विफल। वे डॉकर पुल करने में असमर्थ हैं:

@Mistrained कृपया इसे ठीक करें।

VM पर बनाता है jenkinsNode3VM वर्तमान में विफल। वे खींचने में असमर्थ हैं

मैंने डॉकर छवि को ठीक किया जिसे खींचा नहीं जा सका।

आपका बहुत बहुत धन्यवाद! यह हमेशा मददगार होता है यदि आप लिखते हैं कि क्या गलत था और आपने इसे कैसे ठीक किया।

मुझे नहीं पता कि क्या गलत था, मैंने एजेंट पर मैन्युअल रूप से छवि बनाई। चूंकि एजेंट इसे खींच नहीं सका।

Dockerfile के लिए (scripts/docker/debian/stretch) my Visual Code कहना है कि इसके अंत में 2 emtpy लाइनें हैं, लेकिन vim इसका केवल एक ही कहता है। मुझे पता नहीं है कि इसे ऊपर गलती से कुछ करना है, शायद यह सिर्फ मेरा VS ।

ऐसा लगता है कि हमें अपनी डॉकटर रजिस्ट्री में समस्या है (#3316 डॉकर पुल विफल रहता है unexpected EOF )।

चूंकि रिलीज के बाद धूल जम गई है और कोई निर्माण नहीं चल रहा है, मैं सब कुछ रोकने और रजिस्ट्री को पूरी तरह से साफ करने का प्रयास करने का सुझाव दूंगा। उसके बाद सभी छवियों को उम्मीद से साफ-सुथरा बनाया जाना चाहिए। मैं केवल सुनिश्चित करने के लिए शुरू करने से पहले रजिस्ट्री डेटा का बैकअप लूंगा, लेकिन मुझे उम्मीद है कि एक साफ शुरुआत से कुछ त्रुटियों से छुटकारा मिल जाएगा।

मैं टिप्पणी की प्रतीक्षा करूंगा कि क्या शुरू करने से पहले इसके खिलाफ कुछ है।

मुझे लगता है कि इसमें एक समस्या है

(स्क्रिप्ट/डॉकर/डेबियन/खिंचाव)

छवि, क्योंकि यह केवल एक ही असफल है।

मैंने इसे मैन्युअल रूप से फिर से बनाया है, लेकिन रजिस्ट्री में छवि के साथ निश्चित रूप से कुछ गड़बड़ है।

जेनकींस रिपोर्ट: jenkinsNode3VM (ऑफ़लाइन)

यदि आप किसी तरह की निगरानी स्थापित कर सकते हैं तो @Mistreated बहुत अच्छा होगा।

a7 (और इसलिए v2 और i7 ) नीचे हैं। मैंने व्यवस्थापक से संपर्क किया।

मार्कस 2330 संपादित करें: फिर से ऊपर

TU Wien में 08.07.2020 को एक नियोजित बिजली आउटेज के कारण, हमारा व्यवस्थापक एक दिन पहले (मंगलवार 7.7) सभी बिल्ड सर्वरों को बंद करने की योजना बना रहा है। उस समय के दौरान निर्माण बहुत धीमा होगा, इसलिए कृपया उस दिन केवल अति आवश्यक मामलों में ही आगे बढ़ें।

I7 को छोड़कर सर्वर फिर से ऑनलाइन हैं। मैंने व्यवस्थापक को सूचित किया।

कल शाम को एक और बिजली गुल (अनियोजित) थी, इस प्रकार सभी बिल्ड सर्वर अब डाउन हैं। इस पर प्रशासन काम कर रहा है।

30 मिनट बाद संपादित करें: i7 सहित सब कुछ फिर से ऊपर है: रॉकेट:

@markus2330 ऐसा लगता है कि v2 और i7 ने हाल ही में इंटरनेट एक्सेस खो दिया है (संभवतः बिजली आउटेज के दौरान?) क्या आप किसी भी कॉन्फ़िगरेशन परिवर्तन के बारे में जानते हैं जो हमें करना चाहिए था, क्योंकि इंटरफेस स्थिर रूप से कॉन्फ़िगर किए गए हैं?

मैं किसी बदलाव के बारे में नहीं जानता, केवल इस बारे में कि इन दो बिजली आउटेज (एक नियोजित, दूसरा अनियोजित) के बाद कंप्यूटर फिर से चालू हो गए।

लेकिन आप सही कह रहे हैं, मैं यह भी देखता हूं कि इन दोनों (लेकिन a7 नहीं) के पास अब इंटरनेट कनेक्शन नहीं है, हालांकि वे पहुंच योग्य हैं। मैंने अपने एडमिन से इस बारे में पूछा।

हो सकता है कि जब तक यह समस्या ठीक न हो जाए, हम उन्हें जेनकींस से डिस्कनेक्ट कर दें?

व्यवस्थापक से संपर्क करने के लिए धन्यवाद! मैंने i7 और v2 दोनों को तब तक डिस्कनेक्ट किया जब तक कि समस्या का समाधान नहीं हो जाता। (बिल्ड वैसे भी काम नहीं करते क्योंकि वे डॉकर छवियों को नहीं खींच सकते हैं)

करीब एक हफ्ते पहले किसी ने राउटर से कुछ बदला। व्यक्ति को सूचित किया गया था और उम्मीद है कि इसे जल्द ही ठीक कर दिया जाएगा।

आइए उन्हें अभी के लिए डिस्कनेक्ट कर दें।

इंटरनेट की समस्या अब हल हो गई है और मैंने इन मशीनों पर सुरक्षा अद्यतन भी स्थापित किए हैं।

@mpranj क्या आप कृपया उन्हें फिर से चालू कर सकते हैं?

धन्यवाद @ मार्कस2330।

सभी नोड्स अब ऑनलाइन वापस आ गए हैं।

मैंने नवीनतम पीवीई कर्नेल के लिए बिल्ड सर्वर को रीबूट किया। जेनकींस शीघ्र ही उठना चाहिए।

मैं ले जाया गया

• [ ] बिल्ड विफल होने पर ईमेल भेजना अधिक विश्वसनीय होता है
• [] जेनकिंस उपयोगकर्ता के बिना डॉकर छवि
• [ ] सेंटोस/फेडोरा/आर्क डोकर इमेज
• [] सेंटोस पैकेज
• [ ] फ्रीबीएसडी/ओपनबीएसडी/सोलारिस बिल्ड एजेंट

#3519 पर और ऊपर #3519 से लिंक किया गया।

@robaerd के पास अब a7/v2/i7 तक पहुंच है और परेशानी के मामले में व्यवस्थापक से संपर्क कर सकते हैं।

निर्माण समय की एक त्वरित रिपोर्ट (मुख्य पाइपलाइन libelektra ):

• a7 सक्षम के साथ: 2h 29m 24s
• a7 अक्षम के साथ: 1h 35m 45s

जेनकिंस क्यों प्रदर्शित करता है कि यह बंद हो जाता है? हमेशा यहाँ पहले से पढ़ना अच्छा होगा :wink:

पूर्ण सिस्टम बैकअप और btrfs से ext4 तक फाइल सिस्टम के सुधार के कारण जेनकिंस बंद होने जा रहा है।

जेनकींस फिर से ऊपर है

जेनकिंस सीआई आज लगभग 11:15 सीईटी से रखरखाव के लिए ऑफ़लाइन हो जाएगा।

हम कुछ बैकअप और सफाई कार्य करेंगे और a7 प्रदर्शन को बेहतर बनाने का प्रयास करेंगे।

रखरखाव समाप्त होने पर आपको फिर से सूचित किया जाएगा।

जेनकिंस सीआई और सभी बिल्ड सर्वर फिर से चालू हो गए हैं। a7 को अब बहुत बेहतर प्रदर्शन करना चाहिए, लेकिन इसकी भंडारण क्षमता कम है।

कृपया रिपोर्ट करें यदि आप किसी त्रुटि का अनुभव करते हैं।

जेनकिंस सीआई और बिल्ड एजेंट संक्षिप्त रखरखाव/अपडेट के लिए ऑफ़लाइन होंगे।

संपादित करें: अद्यतन किए जाते हैं।

सर्वर डाउन है, मैं जांच करता हूं।

सर्वर फिर से चालू हो गया है।

कारण के बारे में आधिकारिक बयान: "पास के सर्वर में पीएसयू के साथ एक समस्या थी जिसके कारण सर्वर बंद हो गया था, अब इसे ठीक कर दिया गया है।"

a7 में ssd भरा हुआ है, जिससे सभी बिल्ड विफल हो जाते हैं।

मैं कुछ जगह खाली करने की कोशिश करूंगा। क्या अभी के लिए जेनकींस से a7 बिल्ड एजेंट को डिस्कनेक्ट करना सुरक्षित है?

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

मैं कुछ जगह खाली करने की कोशिश करूंगा। क्या अभी के लिए जेनकींस से a7 बिल्ड एजेंट को डिस्कनेक्ट करना सुरक्षित है?

बेशक। इसके विपरीत, यदि यह सभी बिल्डों को विफल कर देता है, तो इसे कनेक्ट रखना असुरक्षित होगा।

docker system prune -a चलाने से लगभग 50% जगह फिर से साफ हो गई। शायद हमें -a ध्वज जोड़ने के लिए मौजूदा क्रोनजॉब को अनुकूलित करने की आवश्यकता है?

जेनकिंस होम भी काफी जगह का इस्तेमाल कर रहा है।

मास्टर बिल्ड (डिब पैकेज और वेबसाइट बिल्डिंग के साथ पूर्ण पाइपलाइन) किसी तरह अभी भी विफल हो रहा है, भले ही सब कुछ हरा दिखता है। कोई विचार?

community पर फ़ोकल डिब पैकेज का अपलोड फ़ाइल elektra_0.9.3.orig.tar.gz पर विफल रहता है। यह शायद फ़ाइल पर एक अनुमति समस्या है। मैं इसे अभी के लिए निर्देशिका से हटा दूंगा और इसे अगले भाग में फिर से बनाने दूंगा।

किसी भी तरह sshPublisher अगर यह विफल हो जाता है तो मंच को लाल रंग में सेट नहीं करता है।

हो सकता है कि हमें -a ध्वज जोड़ने के लिए मौजूदा क्रोनजॉब को अनुकूलित करने की आवश्यकता हो?

क्या कोई कारण था कि आपने ऐसा क्यों नहीं किया? यदि नहीं, तो एक अच्छा विचार लगता है।

जेनकिंस सीआई और रजिस्ट्री a7 पर वॉचटावर छवि के नए संस्करण में स्थानांतरण के लिए ऑफ़लाइन होगी। केवल कुछ मिनट लेना चाहिए।

संपादित करें: अपडेट किए जाते हैं और जेनकींस सीआई फिर से ऊपर है

जेनकिंस और एजेंट अपडेट के लिए संक्षिप्त रूप से नीचे होंगे।

संपादित करें: सब कुछ अद्यतन किया गया था और फिर से चल रहा है। मुझे एक समस्या को ठीक करने की आवश्यकता थी जहां a7 बस्टर के बजाय डेबियन स्ट्रेच डॉकर पैकेज का उपयोग कर रहा था। मैंने कुछ जगह भी साफ की।

बिल्ड विफल हो रहे हैं क्योंकि a7 पर कोई स्थान नहीं है।

रखरखाव के लिए कुछ मिनटों के लिए बिल्ड इंफ्रास्ट्रक्चर अनुपलब्ध रहेगा।

बिल्ड इंफ्रास्ट्रक्चर फिर से उपलब्ध है।