Libelektra: بناء عناصر الخادم

يارب احفظها

فقط دفع بعض الإصلاحات المتعلقة بنظام البناء. لكنك تحتاج أيضًا إلى إصلاح بعض الحزم على جهازك المستقر ديبيان:

• الرجاء تثبيت qtdeclarative5-dev من Wheezy-backports (يمكنك إزالة /opt/Qt5.3.0 بعد ذلك)
• الرجاء تثبيت java8 كحزمة:
  
  
  
  • استخدم هذه الطريقة: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  
  
  • لنفترض أن cmake تجد 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
  
  
  • قتل + إعادة تشغيل عملية java المحلية jenkins. وإلا ستفشل كل البنيات
  
  
  • اختياري: إزالة jdk7
  
  

تبدو جيدة ، شكرا لإصلاح هذه المشاكل.

لقد قمت أيضًا بهذه الخطوات على عامل debian-stabil.

بالنسبة للأجهزة الأخرى ، لم يكن تثبيت qtdeclarative5-dev ممكنًا ، لأنه يتعارض مع qdbus الذي يحتاجه kde4. لذلك استعدت النص السابق config-debian-Wheezy على أنه config-debian-wheezy-local.

أضفت أيضًا خطوات التثبيت التي ذكرتها كملاحظات في README.md لأنها قد تكون محل اهتمام الآخرين.

شكرا لترقية الوكلاء!

الأشياء المفقودة على الاسطبل

1.) اللاتكس (+ أعتقد أن هناك حاجة أيضًا إلى مادة texlive-latex الموصى بها)
انظر 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.) هل يمكنك تثبيت رنة (بالنسبة إلى elektra-clang ، لن تعمل رنة الصرير)؟
3.) هل يمكنك تثبيت mingw + wine لـ elektra-gcc-config-mingw؟

apt install --no-install-recommends doxygen-latex + رنة + mingw انتهى

لماذا تحتاج النبيذ؟

راجع للشغل ، يجب تغيير i586-mingw32msvc-X إلى i686-w64-mingw32-X في Toolchain-mingw32.cmake . في الوقت الحالي ، لن يعمل هذا في حالة عدم الاستقرار.

شكرا لك على docu!

النبيذ ضروري لتنفيذ ثنائيات النوافذ المجمعة (على سبيل المثال ، exporterrors.exe)

أعتقد أنك قمت بتثبيت mingw الذي يبني لـ w64. في حزمة mingw32 ، لا يزال هناك /usr/bin/i586-mingw32msvc-c++ .

ومع ذلك ، فإن ملف toolchain الجديد الخاص بـ w64 موضع تقدير.

لقد قمت بتثبيت gcc-mingw-w64-i686 وهو الإصدار x64 من mingw مع i686 كهدف.
الحزمة mingw32-binutils مهملة وغير متوفرة في حالة عدم الاستقرار بعد الآن.

النبيذ مثبت على كلا الحاويات.

في الواقع ، لا بد أن يكون بناء mingw مستقرًا ، لذلك لا ينبغي أن يكون ذلك مشكلة.

MinGW-w64 هو شوكة في mingw وهو هدف مختلف تمامًا. لم يختبره أحد حتى الآن.

شكرا لتركيب النبيذ

تبدو Mingw-w64 متفوقة. ربما حان الوقت للمضي قدمًا :-)

نرحب بالمساهمات ؛) ليس لدي أي آلة لاختبارها.

أخشى أنك حصلت على النبيذ الخاطئ ، يجب أن يكون من المناسب الحصول على تثبيت wine32

انظر أيضا http://build.libelektra.org : 8080 / job / elektra-gcc-config-mingw / 218 / console

لا.

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

حسنًا ، سيحل هذا dpkg --add-architecture i386 . ولكن لا يمكنك فقط تثبيت وظيفة mingw / wine على آلة البناء الخاصة بك؟ إعداد mingw خاص إلى حد ما.

تحرير: سأرى ما إذا كان بإمكاني الحصول على elektra build باستخدام mingw-w64 ، لذلك لا أحتاج إلى تثبيت الكثير من i686 libs.

المشكلة هي أنه ليس لدي آلة جيسي احتياطية ولا يعرف مينج ويزي C ++ 11.

تمكنت من الحصول على عمل mingw-w64. ومع ذلك ، فإن std :: mutex غير متاح لأنه لا يوجد glibc على النوافذ و std :: mutex يعتمد على pthreads. أيه أفكار؟

مدهش، شكرا!

هل يؤدي إلى خطأ في التجميع؟ لا يتم استخدام std :: mutex للداخلية
وظيفة ، ولكن فقط في ملف الرأس ليتم تضمينها من قبل المستخدم. يتم استخدامها
في حالات الاختبار بالرغم من ذلك.

يتمثل أحد الحلول لمشاكل التجميع في توفير std :: mutex في mingw
رمي حالة أخطاء النظام في كل محاولة للقفل / فتح. في الواقع ، سأفعل
نتوقع من الناس mingw على الأقل تقديم شيء من هذا القبيل (على سبيل المثال متى
تم تعيين بعض وحدات الماكرو ، على غرار -D_GLIBCXX_USE_NANOSLEEP)

https://github.com/meganz/mingw-std-threads قد يكون طريقة أخرى. لكن هذا هو
على الأرجح مفيد فقط إذا كانت جميع حالات الاختبار باستثناء تلك التي تتضمن std :: mutex
تعمل بالفعل.

في الأساس ، هذا هو مثيل واحد فقط من C ++ 11 غير متوفر بشكل صحيح.

حالة mingw الآن:

• أضاف dlfcn-win32 كمشروع خارجي إلى libloader. بهذه الطريقة يقوم cmake بسحب + تجميع المكتبة كخطوة بناء إضافية. أقوم بربط الأرشيف لتجنب إدارات dll الإضافية.
• أضاف تبعية winsock2.h / ws2_32.dll إلى cpp11_benchmark_thread. مطلوب بواسطة gethostname () - مكالمة

أقوم حاليًا بالتشييد باستخدام -static-libgcc + -static-libstdc++ . خلاف ذلك النبيذ غير قادر على العثور على dlls. لا يتم تجميع كائن المزامنة الإضافي أيضًا. حاولت mingw-std-thread. حصلت للتو على المزيد من أخطاء الترجمة :-)

إذا قمت بالتبديل من x86_64-w64-mingw32-X إلى x86_64-w64-mingw32-X-posix std :: تجميع كائن المزامنة بشكل جيد ، لأنه يتم تعريف عناصر pthread. ومع ذلك ، أحصل على تبعية إضافية لـ libwinpthread-1.dll ، والتي يتعذر على النبيذ العثور عليها.

أعتقد أن أفضل رهان لدينا هو استخدام x86_64-w64-mingw32-X-posix رغم ذلك.

مرة أخرى ، أنا مندهش من أن لديك هذه المشكلة. حتى الآن كنا سعداء عندما حصلنا على ملف libelektra.dll.

لا يمكنني قول أي شيء عن هذا القرار x86_64-w64-mingw32-X-posix ، لأنني لا أستخدمه ولا أعرف الآثار المترتبة عليه. أنا أتساءل عن وجود مثل هذا البوزيكس ليب ، اعتقدت أن نهج طبقة البوزيكس هو cygwin وليس mingw.

هل هذا القرار له تأثير حتى على libelektra.dll؟ إذا كان الأمر يتعلق فقط بحالات الاختبار ، فلن يهتم أحد (طالما أن خادم الإنشاء قادر على تشغيله). إذا تم تشغيل حالات الاختبار ، فستكون فائدة كبيرة. (راجع # 270 حيث كشفت اختبارات الوحدة عن بعض الأخطاء الغريبة على نظام التشغيل Mac OS X)

يبدو أنه يمكن تنزيل libwinpthread-1.dll ، لا أعرف ما إذا كانوا يعملون مع النبيذ أم لا؟ هل يمكنك إضافته أيضًا كمشروع خارجي مثل ما تم باستخدام dlfcn-win32 (بحيث يتم التعامل مع جميع ملفات dll بنفس الطريقة)؟ خلاف ذلك ، إذا كنت بحاجة إلى تنزيل 1 أو 3 dlls للاختبارات ، فقد لا يهم حقًا (مرة أخرى ، أنا لست مستخدمًا ، ولا أفهم مفهوم النشر ، إذا كان هناك أي من Windows dlls).

beku ما رأيك؟ هل لديك الوقت لاختبار أحدث إصدار من 0.8.13 mingw-w64 على Windows مع oyranos؟

هل يتم تمكين الاختبارات عادة لوظيفة بناء mingw؟ بالأمس تم تعطيل كل منهم.

نعم ، لقد تم تعطيلهم. ولكن تم تعطيل أمثلة / معايير Afaik مثل cpp11_benchmark_thread أيضًا. لذلك اعتقدت أنك غيرتها وجمعت أكثر مما كان عليه في السابق.

قمت بتجميع الريبو بالكامل مع تمكين C ++ 11. لا شيء آخر.

لكن الملفات التنفيذية مثل bin / basename.exe التي تم إنشاؤها باستخدام -posix تعمل بشكل جيد طالما قمت بنسخ ملفات dll المطلوبة إلى دليل bin (شكرًا لك على النوافذ لعدم وجود RPATH). لم أجد طريقة إلى أ) السماح لـ cmake بالعثور على دليل dll + b) نقطة النبيذ إلى دليل dll.
اعتقدت أن الارتباط الثابت سيعمل ولكن بعد ذلك يفشل البناء برموز مكررة أثناء ربط elektra dll. لأن دلل يحتوي بالفعل على الرموز المدرجة.

@ markus2330 تمكنت من الحصول على elektra 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-> اسم الملف NULL

pk من النوع resolverHandles.user

حاولت إلقاء نظرة على المكون الإضافي لكنني فشلت في فهم الحلقة المقدمة في elektraWresolverOpen . تستدعي الحلقة elektraWresolveFileName -> elektraResolve{Spec,Dir,User,System} وكلها malloc resolverHandle->filename وبالتالي تسرب الذاكرة.

شكرا لتوضيح ذلك! من الواضح أن الكود مكسور منذ المقدمة في c87ae8e87a716b02b2c7ed790ad56a89d95547a9
أثناء التكرار فقط ودائمًا تمت تهيئة مقبض النظام. هذا يؤدي إلى تعطل عند استخدام مساحة اسم أخرى.

أصلحته في
edb4d50856bb5331749220de5a83fa2062624a9d

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

لكن imho يكفي إذا كان هناك متغير واحد فقط (التجميع الثابت) يعمل. من الرائع مشاهدة أداة kdb قيد التشغيل!

أين يمكنني أن أجد edb4d50856bb5331749220de5a83fa2062624a9d؟

تم دفع edb4d50856bb5331749220de5a83fa2062624a9d لاحقًا.

ما هي إصدارات دول مجلس التعاون الخليجي المثبتة على debian-unstable-mm؟

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

يقول أنه لا يوجد دول مجلس التعاون الخليجي 5.2

هل يمكنك تثبيت أكبر قدر ممكن من المترجمات ، من فضلك؟

في بعض القضايا أو العلاقات العامة قلت إنني أزلت جميع المجمعين باستثناء الأحدث.
تحرير: مجلس التعاون الخليجي 4.9 عند الاستقرار ، 4.9 + 5.x (افتراضي) في حالة عدم الاستقرار

يرجى إجراء هذا النوع من الاختبارات (أجدها غير ضرورية للغاية على أي حال) على حاوياتك الخاصة. لن يبقى منجم إلى الأبد على أي حال.

أنا لم أقرأ ذلك. ربما يكون لكل منهما 50 ميغا بايت. هل يمكنك تثبيتها مرة أخرى والإجابة على السؤال الأول من فضلك؟

ربما أخبرتك في اجتماعنا. لكني أخبرتك بالتأكيد.

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

يسمى الإصدار الثنائي المحدد gcc-5. لا توجد حزمة منفصلة للإصدارات الثانوية بعد الآن. لذا فإن التكوينات متعددة الأشكال لدول مجلس التعاون الخليجي مع هذا المستوى من التفاصيل قد عفا عليها الزمن نوعًا ما. أوصي بإزالة gcc 4.7 واستبدال gcc-5.2 بـ gcc-5 والانتهاء من ذلك.

المترجم الإضافي الوحيد المتاح الذي لم أقم بتثبيته هو gcc-4.8. وقد تم بالفعل وضع علامة على gcc-4.8 للإزالة.

شكرا للمعلومة! يبدو أن أيام المجد للعديد من المترجمين المتاحين قد ولت.

لقد أصلحت تعدد الأشكال غير المستقر.

سأغلق الآن ، شكرًا لإعداد الوكيل الممتاز.

مرحبًا ، جيسي (مستقر) يحتاج إلى المزيد من الحزم. هل يمكنك تثبيت:

• [] fakeroot
• [] gpg (+ إنشاء مفتاح لـ [email protected])
• [] reprepro (ربما تم تثبيته بالفعل ، لم يتم تنفيذ البرنامج النصي حتى الآن)

تم تثبيت fakeroot ، تم تثبيت gpg + repropro بالفعل.
هل يمكن أن ترسل لي مفتاح gpg الموجود بالفعل؟ لذلك كلا آلات البناء لها نفس الشيء

لا بأس أن يكون لديك مفاتيح gpg مختلفة. لست متأكدًا مما إذا كان الإعداد الحالي يستخدمها على الإطلاق ، لذا انتظر أولاً إذا فشل http://build.libelektra.org : 8080 / job / elektra-git-buildpackage-jessie / 2 /.

• تم تثبيت debhelper + libsystemd-journal-dev
• python-dev تبعية خاطئة. يجب أن يكون python2.7-dev أو python3-dev أو كليهما
• لماذا نحتاج إلى دعم بيثون؟

شكرا للتثبيت!

python-dev متاح لـ Jessie و python-support أيضًا. الرجاء تثبيتها.

لقد اختبرته محليًا ، عندما يتم تثبيت هذه الحزم ، فإنه يبني من أجل جيسي.

بالتأكيد ، إنه متاح ولكنه تبعية خاطئة. يعتمد python-dev على python2.7-dev وهو _ not_ كافٍ. بدلاً من ذلك ، يلزم استخدام python2.7-dev + python3-dev.

دعم python ليس مطلوبًا على الإطلاق imho.

لا أعرف لماذا تم اختيار التبعيات بهذه الطريقة ، فقد تم تنفيذ معظم عمليات التغليف بواسطة iandonnelly أثناء gsoc.

نعم ، يجب تحديث الحزم لإنشاء روابط python3 أيضًا. حاليا ، ببساطة لم يتم القيام به. ومع ذلك ، يمكنك تثبيت python3-dev ، حتى لا ينكسر البناء (عند إضافة روابط python3 + plugins إلى حزمة debian).

هذا لا يعني أنهم على صواب :-) - أنا متأكد تمامًا من إدارة python-dev.
هل يمكنك استبدالها وإزالة قسم دعم الثعبان؟

تم تثبيت python3-dev و python2.7-dev بالفعل. وإلا فلن يبنى أي ارتباط.

بالمناسبة. حزمة دبيان الرسمية من دبيان" مضيعة للوقت ، فإن عمل الأفضل على أي حال.

عندما أجد الوقت ، سوف أقوم بتحديث فرع "debian" لدينا إلى ما فعله pinotree في الحزمة الرسمية. لقد سمح لنا بالفعل بالقيام بذلك. سأنتظر تحديث qt-gui ، حاليًا لا داعي للتغيير. وسيكون الحصول على دعم python2 أمرًا مهمًا لعملية تثبيت واحدة (حيث يتم استخدام الفهد ، والذي لن يعمل مع python3).

لم أقل أبدًا أنني سأزيل حزم python2. كل ما أقوله هو أن python-dev هو تبعية غير دقيقة. نحن نطلب إصدارات صريحة. لذا فإن pythonX-dev هو التوزيع الصحيح للاستخدام.

نأمل أن يكون pinotree قد عمل على التبعية بشكل صحيح.

راجع للشغل ، الفهد مات. لا تستخدمه.

حسنًا ، استبدله. يرجى الرجوع إلى b7c266b36b0ab0fad9120e67a457b580c7c44690 وتثبيت دعم python إذا لزم الأمر بعد كل شيء.

أنا متأكد من أن بينوتري فعل ذلك بشكل صحيح ؛)

وهي تقول: dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
http://community.markus-raab.org : 8080 / job / elektra-git-buildpackage-jessie / 3 / console

المثبتة

python-dev تبعية خاطئة. يجب أن يكون python2.7-dev أو python3-dev أو كليهما

• python-dev بتثبيت حزمة التطوير لإصدار Python 2 الافتراضي ؛ منذ Wheezy ، هذا هو Python 2.7
• python3-dev بتثبيت حزمة التطوير لإصدار Python 3 الافتراضي ؛ Python 3.2 في Wheezy و 3.4 في Jessie وما زال حتى الآن 3.4 في Stretch (أعتقد أنه سيكون 3.5 قريبًا)

لذلك ، إذا كنت ترغب في البناء مقابل إصدار Python 2/3 الافتراضي ، فاستخدم على التوالي python-dev / python3-dev ، وليس إصدارات pythonX.Y-dev (التي تحتاج إلى استخدامها عند صراحة تريد تثبيت إصدار دقيق من Python ، حتى لو لم يكن الإصدار الوحيد المثبت على النظام ، وليس الإصدار الافتراضي). استخدام أي منهما هو ما أوصي به.

من وصف python-dev :
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

وفقًا لهذا النص ، يمكن أن يعتمد Python-dev بالتأكيد على python3 في وقت ما قريبًا

علاوة على ذلك: لن يكون هناك إصدار آخر من python2. لذا فإن python2.7-dev سيكون آخر حزمة مطور من python2 على الإطلاق.

بالاعتماد على 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

انتهى

شكرا لك!

يرجى تصدير / home / jenkins / repository عبر http.

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

→ http://194.117.254.29/elektra-stable/

manuelm هل يمكنك من فضلك تثبيت ronn على الوكلاء؟ (مطلوب لإنشاء صفحات بشرية)

apt-get install ruby-ronn

انتهى

شكرًا ، تم إعادة بناء حزم jessie مرة أخرى ، وتم تضمين صفحات الرجل الآن!

الرجاء تثبيت musl ، أي

apt-get install musl musl-dev musl-tools

شكرا لك!

موسل مثبتة وأجندات مطورة

شيئان مهمان حول خادم البناء:

1. لا تقم بإنشاء وظائف فارغة جديدة ، بل مكررة ، فهي تحتوي على إعدادات صحيحة (باستثناء ما هو مذكور في الرقم 2.).
2. يجب أن نستخدم النسخ المرجعية (في / home / jenkins / libelektra) أو نفضل الحيوانات المستنسخة الضحلة لكل مهمة بناء (يتم تنفيذها حاليًا فقط للبعض ، مثل elektra-clang). حاليًا ، تبلغ حركة المرور أكثر من 300 ميجابايت في عمليات التنفيذ بسبب العديد من عمليات الاسترداد غير الضرورية.

mpranj سيكون رائعًا إذا

@ markus2330 فقط للتأكد: يجب أن أطبق نفس سلوك الاستنساخ على جميع وظائف البناء كما هو الحال في elektra-clang ؟

يتم تطبيق النسخ الضحلة على جميع وظائف البناء باستثناء :

• [] elektra-git-buildpackage-jessie
• [] elektra-git-buildpackage-Wheezy
• [] elektra-multiconfig-gcc-Stable
• [] elektra-multiconfig-gcc-unstable
• [] elektra-source-package-test

تحقق هذه الوظائف من بعض الدليل الفرعي. لم أكن متأكدًا مما تريده هناك ، لذلك سأتركهم كما هم الآن.

شكرا لك! نعم ، إنهم بحاجة إلى محفوظات وفروع كاملة ، والنسخ الضحلة لا معنى لها ولكن مستودع النسخ المرجعي سيكون مفيدًا.

تم تحديث Jenkins إلى 1.651.2. كما تم تحديث كافة المكونات الإضافية.

سأبقي المشكلة مفتوحة لاستنساخ المرجع. يجب أن يكون لدينا أيضًا "وظائف cron" التي تقوم بتحديث المستودعات من وقت لآخر ، بشكل مثالي باستخدام جينكينز نفسها.

توقف Jenkins عن بناء بعض الوظائف (منذ التحديث على ما يبدو). فشل مع
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

شكرا للمعلومة. أحاول تخفيض إصدار طلب github builder من 1.31 إلى 1.14.

يبدو الآن أنه عالق عند تعيين حالة الإنشاء لـ Github الالتزام. إنها تحذر من أن هذا تم إهماله في config.

حاولت أيضًا الرجوع إلى إصدار أقدم من كل مكون إضافي باستخدام *git* في اسمه ، ولكن لا تزال هناك أخطاء (خطأ غريب متعلق بـ Mailer Plugin ، الرجوع إلى إصدار Mailer Plugin لم يساعد). لذلك قمت بتحديث كل شيء إلى الإصدارات الحديثة مرة أخرى. يبدو أن المشكلة هي مشكلة معروفة في المنبع:

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

آمل أن يصلحوها قريباً.

سؤال آخر: هل يعرف شخص ما كيفية تشغيل وظائف متعددة لكل علاقات عامة؟ (أود تشغيل كلاً من elektra-mergerequests-stabil و elektra-mergerequests-unstable)

تعمل الوظيفة elektra-test-bindings بشكل جيد مع الإنشاءات ذات المعلمات (كما هو موضح أيضًا في بطاقة المنبع). ألا يمكننا تحويله إلى إنشاءات ذات معلمات فقط؟ تم الإبلاغ عن الخطأ في المنبع لفترة من الوقت ، ولا أرى أنه تم إصلاحه قريبًا.

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

من الناحية المثالية ، يمكن تنفيذ كل وظيفة من خلال جيثب PRs أيضًا. (باستثناء المهام الخاصة بالمهام غير المتعلقة بالعلاقات العامة التي تقوم بتحديث docu أو تغطية الفرع الرئيسي)

من عيوب تكوين elektra-test-bindings أنها تقوم فقط بالاستقصاء وتستغرق وقتًا طويلاً حتى تبدأ في البناء (حتى 5 دقائق). لا أريد تنشيط "استخدام خطافات github لتشغيل الإنشاء" ، على الرغم من ذلك ، لعدم كسر مهمة الإنشاء.

بالمناسبة. هل أنت متأكد من أن خيار "الاستنساخ الضحل" مناسب لوظائف github pullrequest builder؟

أتساءل كيف تختار جيثب وظيفة البناء التي تستخدمها للعلاقات العامة الجديدة. لماذا لم يتم اختيار روابط elektra-test-bindings و elektra-ini-mergerequests للعلاقات العامة الجديدة؟ لماذا هي أحيانًا طلبات elektra-mergere-غير مستقرة وأحيانًا elektra-mergerequests (-stable)؟

manuelm هل لديك أي فكرة؟

بالمناسبة. بطريقة ما ، يكون الاتصال بوظائف البناء المكتملة و github ضعيفًا بشدة (حتى بالنسبة لربط elektra-test-bindings). تقول الآن في كل عملية إنشاء تقريبًا "لم تكتمل بعض عمليات التحقق بعد".

من عيوب تكوين elektra-test-bindings أنها تقوم فقط بالاستقصاء وتستغرق وقتًا طويلاً حتى تبدأ في البناء (حتى 5 دقائق).

وهذه مشكلة لأن؟ يستغرق الاختبار أكثر من 5 دقائق على أي حال.

لماذا لم يتم اختيار روابط elektra-test-bindings و elektra-ini-mergerequests للعلاقات العامة الجديدة؟

لماذا يجب؟ elektra-test-bindings بواسطة "عبارة التشغيل" فقط. ليس لدي فكرة ما هو elektra-ini-mergerequests .

لماذا هي في بعض الأحيان elektra-mergerequests-unstable وأحيانًا elektra-mergerequests-مستقرة؟

المستقر / غير المستقر جديد؟ لست متأكدًا من إمكانية تشغيل وظائف متعددة لكل علاقات عامة جديدة. كنت سأفعل وظائف فرعية.

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

الخمس دقائق هي مشكلة عندما تريد تصحيح أخطاء خادم البناء. وما زلت آمل أن نحصل على اختبار أول سريع في وقت ما ، يستغرق حوالي 5 دقائق.

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

تحدث شخص ما عن مشاريع جيثب حيث لديهم وظائف متعددة تعمل لكل علاقات عامة. (يُعرض بشكل فردي)

ما هو subjob؟ هل تقصد multijob ؟

تحدث شخص ما عن مشاريع جيثب حيث لديهم وظائف متعددة تعمل لكل علاقات عامة. (يُعرض بشكل فردي)

سيتعين عليك إضافة خدمتين على جيثب.

ما هو subjob؟ هل تقصد multijob؟

نعم multijob.

راجع للشغل ، ماذا عن https://docs.travis-ci.com/ ؟ يدعم Travis OSX.

أعلم أنه لن يحل محل jenkins ولكنه قد يحل محل العلاقات العامة / في كل عمليات إنشاء. لا يزال بإمكان Jenkins إجراء اختبار المترجم المتعدد / إلخ.
تحرير: ترافيس لديه حتى gcc + clang.

متفق عليه ، سيكون من المثير للاهتمام استخدام طاقة وحدة المعالجة المركزية / الكهرباء الخاصة بهم مجانًا لأن elektra مفتوحة المصدر.

من المحتمل أن العلاقة بين جيثب وجينكينز هي في الواقع 1: 1. في خدمة github ، دخلت إلى http://build.libelektra.org : 8080 / github-webhook / ولم أجد طريقة لإنشاء عنوان URL آخر في jenkins. (لم أجد سوى طريقة حول كيفية تحديد التجاوز ، لكن هذا لم يُنشئ عنوان URL جديدًا).

في https://github.com/janinko/ghprb/issues/142 ناقشوا أنه يجب أن "يعمل فقط"؟ (بدون إضافة خدمات متعددة)

ومع ذلك ، يجب حل مشكلة sha1 الآن. تم كسره لأن Jenkins قدم مقياسًا أمنيًا جديدًا يعمل على تقليم متغيرات البيئة غير المعروفة. I ثابتة كما اقترح (المضافة -Dhudson.model.ParametersAction.safeParameters = ghprbActualCommit، ghprbActualCommitAuthor، ghprbActualCommitAuthorEmail، ghprbAuthorRepoGitUrl، ghprbCommentBody، ghprbCredentialsId، ghprbGhRepository، ghprbPullAuthorEmail، ghprbPullAuthorLogin، ghprbPullAuthorLoginMention، ghprbPullDescription، ghprbPullId، ghprbPullLink، ghprbPullLongDescription، ghprbPullTitle، ghprbSourceBranch، ghprbTargetBranch، ghprbTriggerAuthor، ghprbTriggerAuthorEmail، ghprbTriggerAuthorLogin، ghprbTriggerAuthorLoginMention، GIT_BRANCH، sha1 to / etc / default / jenkins).

حول استخدام خوادم بناء إضافية: نعم ، تفضل. كما أنه يحل مشكلة وظائف البناء المتعددة لعلاقات عامة واحدة ؛) لم أستخدم ترافيس سي ، لذلك لا يمكنني قول أي شيء عنها. لقد منحت الإذن بأن travis لديه حق الوصول إلى ElektraInitiative.

أول بناء ترافيس: https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
أعتقد أننا بحاجة إلى ملف يامل حتى يعرف ترافيس ما يجب فعله.

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

أنا أعمل على ترافيس (أو أتحقق من بعض الأشياء)

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

أنا بالفعل أقسم بصوت عال

- تعذر العثور على JNI (مفقود: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
- استبعاد البرنامج المساعد jni لأن jni غير موجود

لا يمكنني الحصول على تكوين مكون جافا الإضافي بشكل صحيح. ومع ذلك ، تعمل روابط Java. على دبيان غير مستقر. أيه أفكار؟ إن النظر إلى وحدة cmake لا يساعد كثيرًا.

تحرير: /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

دبيان غير مستقر مبني داخل حاوية عامل إرساء. لكن البناء يستغرق وقتاً طويلاً.
أي أفكار جيدة؟

غالبًا ما يكون clang أسرع فيما يتعلق بوقت البناء ، لكنني أعتقد أن تثبيت التبعيات هو ما يستغرق قدرًا كبيرًا من الوقت

ألا توجد صورة عامل إرساء دبيان أقل من تلك المستخدمة؟ يبدو أنه يتم تثبيت الكثير من الحزم التي لا ينبغي أن تكون ضرورية.

sirblackheart ما الذي يجعلك تعتقد ذلك؟ https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

manuelm على الأرجح ترقية

رقم ترقية التوزيع قصير. ربما دقيقة. يستغرق تثبيت أقسام البناء حوالي 50٪ من الوقت.

أنا أدفع صورة البناء إلى hub.docker.com الآن. اتمنى ان تسرع الامور لكن الصورة 1.9 جيجابايت

الوقت المنقضي 14 دقيقة و 8 ثوانٍ

لست متأكدًا مما إذا كان بإمكاننا القيام بعمل أفضل بكثير

كما قلت ، رنة ربما تحصل لنا 2-3 دقائق. على الأقل بالنسبة لمشروع aseprite
https://travis-ci.org/aseprite/aseprite

سيكون من المفيد أن يكون لديك كلا المجمعين على أي حال.

خطرت للتو فكرة أثناء تحضير عناصر العمل: ماذا لو استخرجنا مسارات جميع الالتزامات في طلب الدفع وقمنا ببناء روابط / مكونات إضافية فقط إذا تأثرت؟ على سبيل المثال

• التغيير في cmake / * يقوم بتشغيل كل شيء (الإضافات + الروابط)
• التغيير في src / bindings / foo يؤدي إلى تشغيل الربط foo
• التغيير في src / plugins / foo triggers plugin foo
• التغيير في كل شيء لا يجمع أي ملحقات + روابط

لا يزال لدينا الجينكينز يوميًا / مرتين يوميًا.

manuelm فكرة جيدة ، @ tom-wa سيكتب مثل هذا السيناريو ، هل يمكنك إنشاء إصدار جديد لهذا؟

mpranj : تذكير: أضف

@ markus2330 الآن أنا أفهم نهج manuelm docker ، لن يدعم travis ubuntu 16.04 حتى العام المقبل ، لذا فإن عامل الإرساء مطلوب للحصول على جميع التبعيات التي لا تحتويها ubuntu 14.04 = swig3.0 libsystemd-devel.

أنا آسف لأنني لم أستطع حضور الاجتماع اليوم. في العمل ، ما زلنا نستعد لإطلاق برنامج كبير اليوم ، لذا لا يمكنني مغادرة المكتب. ولكن في غضون فترة تأخير قصيرة يمكنني الرد على رسائل البريد الإلكتروني.

لقد بدأت في إضافة إصدارات OS X لـ travis منذ يومين: https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
البناء هنا: https://travis-ci.org/manuelm/libelektra/builds/130898079
افتح الأشياء هنا:

• [] فشل cryto_openssl في التحويل البرمجي
• [] فشل اختبارات الربط
• [] لا جافا

يسعدني أن يتولى أي شخص عملي من هنا. ليس لدي OS X وأنتظر travis لفحص ملخصات نظام OSX بسرعة كبيرة.

re: docker: نعم ، إصدار travis الافتراضي ubuntu لا يعمل بشكل جيد. حتى cmake قديم جدًا.
يستغرق إحضار صورة عامل الإرساء التي تم تحميلها حوالي 3 دقائق فقط. وإضافة المزيد من الصور أمر لا يحتاج إلى تفكير. لذلك أعتقد أن هذه طريقة رائعة لحل أي عيوب في بيئة ترافيس لينوكس الافتراضية (أو قد تكون بعد التحديث).

لم أكتشف طريقة جيدة لدمج مراحل البناء والاختبار المختلفة لـ libelektra (cmake + make + make test) مع عامل الإرساء (build + run) + travis (before_install ، before_script ، script). تخرج حاويات Docker بعد اكتمال الأمر. نظرًا لأنه من المفترض أن يتم التخلص من حاويات الرصيف ، فلا يمكنك استئنافها بعد ذلك. لذلك تختفي حالة القرص / الترجمة ، إلا إذا قمت بتركيب دليل محلي في الحاوية. سيستمر العمل على عامل ميناء الاسبوع المقبل.

manuelm رائع ، لقد وصلت إلى أبعد من ذلك ثم فكرنا. سيكون نظام التشغيل Mac OS X للعلاقات العامة والالتزام رائعًا حقًا. يستخدم الكثير من الأشخاص نظام التشغيل Mac OS X الآن ولا أريد كسر البنية لهم مرارًا وتكرارًا. في اجتماع اليوم ، قال mpranj إنه سوف يلتقط عملك. هل تريد إنشاء علاقات عامة مع ملف ترافيس؟

لا ، حيث لا يزال يتعين تعديل ملف travis بعد ذلك. وإلا فإنه سيبني OS X فقط. أفضل ما إذا كان mpranj يأخذ ملف travis الخاص بي

ملاحظة: من فضلك قم باختبار travis في ريبو بمساحة اسم مستخدم. ستفعل الكثير من الدفعات :-)

mingw64 يبني على العلاقات العامة المضافة ، يجب أن يعمل. آسف للتأخير. سأبحث في ترافيس اليوم!

هل هناك جانب سلبي لتمكين تشغيل وظائف البناء بعبارة في العلاقات العامة (مع Github PR builder)؟

أرغب في تكوين الوظائف من # 745 حتى أتمكن من اختبار ما إذا كنت قد أصلحتها ، ولكن يمكنني تطبيقها على معظم / (جميع) وظائف الإنشاء.

تحرير: أفضل عدم بدء جميع الوظائف تلقائيًا ، فلدينا عدد غير قليل بالفعل.

أعتقد أنها فكرة جيدة إذا كان بإمكاننا تكوين كل وظيفة ليتم تشغيلها بعبارة. أعتقد أن هناك جانبًا سلبيًا صغيرًا (على الأقل بالنسبة لربط elektra-test-bindings): عليك إدخال الفرع الذي تريد إنشاءه ولا يمكنك الضغط ببساطة على "إنشاء وظيفة الآن". سيكون رائعًا إذا وجدت حلاً لذلك.

وأنت محق في ذلك ينبغي علينا بالأحرى تقليل الوظائف التلقائية.

يوجد في الواقع حل بسيط للغاية. نحن نستخدم المتغير (env) sha1 لبناء العلاقات العامة. تطالبك الإنشاءات ذات المعلمات بالقيمة ، سواء تم تعيين قيمة افتراضية أم لا.

الحل: اضبط المتغير env sha1 إلى master (في تكوين jenkins نفسه) وقم بتعطيل الإنشاءات ذات المعلمات. إذا لم يكن هناك اعتراض على تعيين المتغير ، فسيحل هذا بالضبط ما ذكرته أعلاه @ markus2330.

لقد قمت بالفعل بتعيينه ، لذا يمكنك الضغط على زر الإنشاء هذا على سبيل المثال elektra-mergerequests وسيبدأ في إنشاء سيد.

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

أعتقد أنه سيحل أيضًا مشكلة متغير البيئة المصفاة ، التي كان لدينا سابقًا.

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

لقد انتهيت تقريبًا من تطبيق هذا على جميع الوظائف (لكن الخادم _just_ أصبح بطيئًا جدًا).
لم تنطبق على الوظائف التي تبني أحرف البدل ** (مستند وبعض أخرى ، لكن عدد قليل جدًا)

يمكنك دائمًا إيقاف إنشاء مهام عندما تريد العمل عليها إذا قمت بإعادة تشغيلها لاحقًا (باستثناء وقت الإصدار). عادة ، جنكينز نفسه هو سبب تباطؤ الآلة. في الوقت الحالي ، قد تكون rsync من نسخة احتياطية هي المشكلة ، لكنها ملحة.

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

الأخبار @ ElektraInitiative / elektradevelopers:

• كما ذكرنا ، يمكن إنشاء كل شيء تقريبًا الآن من العلاقات العامة و / أو الضغط على زر الإنشاء فقط
• عبارات التشغيل هي دائمًا اسم الوظيفة بدون البادئة elektra- . (على سبيل المثال إلكترا-رنة: جنكينز بناء رنة من فضلك) لم أغير jenkins build please والعبارات القديمة الأخرى لأسباب الإرث
• رسالة حالة github build هي دائمًا اسم وظيفة البناء بالضبط

شكرا لك ، أحسنت! يرجى تحديث doc / GIT.md حتى يعرف الجميع العبارات التي تعمل الآن.

(آمل أن يعمل @mention لرسالة واحدة فقط ولا يقرأ الجميع كل رسالة نكتبها هنا)

يبدو أن إصدار Mac OS X الخاص بإصدار xcode 6.1 معطل:
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

لقد أطلقت عملية إعادة بناء لذلك ، لكن يبدو لي أنه فشل مؤقت في ترافيس.

هل يمكنك توثيق كيفية إعادة إنشاء بناء للعلاقات العامة؟ لم أكن أعلم أنه من الممكن.

مباشرة على travis-ci.org ، باستخدام الرابط الخاص بك أعلاه:

أشك في أن هذا يستحق المستند ولكن يمكنني ذلك مع ذلك.
البناء لا يزال لا يعمل فقط بسبب بوابة الخروج. لا أعتقد أن هذا خطأنا.

آه. أعتقد أنك قمت بدمجه قبل بدء / بدء البناء في المقام الأول.
عندما أقوم بإعادة بناء العلاقات العامة الأخرى الناجحة سابقًا ، يتم كسرها أيضًا.

هذه مشكلة ترافيس أكثر من أي شيء آخر.

حسنًا ، شكرًا لك على التحقيق.

يبدو أن manuelm debian-

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

قد يكون ناتجًا عن تحديث jenkins أو إنشاء 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"

علاوة على ذلك ، يجب علينا إنشاء وظائف للبناء تعمل على تحديث الريبو العالمي. المهام الفردية انظر أعلاه.

يمكن أن يساعد الريبو العالمي بالتأكيد في تقليل النطاق الترددي. قد يكون إنشاء البرامج النصية في المصدر فكرة جيدة أيضًا ، على الأقل سيتم تتبعها عن طريق git.

لست من محبي المساحات في المسارات ، لكن بالتأكيد.

بناء سريع في passwd كسر؟

وظيفة البناء السريع مزعجة ، أحاول إزالة kdberrors.h من كل بناء ومعرفة ما إذا كان يعمل بشكل أكثر سلاسة بعد ذلك. على المدى الطويل ، يعتبر اقتراح

أعتقد أن # 894 يعمل على إصلاح البنية السريعة أيضًا ، سأعلق على السطر الذي يزيل kdberrors.h.

بعض الوظائف معطلة ، على سبيل المثال وظيفة مستند html.

mpranj هل لديك الوقت للنظر في ذلك؟

@ markus2330 تم. لا يبدو أن فشل البناء المتبقي متعلق ببناء النظام.

mpranj شكرا لك! ماذا فعلتم لإصلاح ذلك؟ أعتقد أنه سيكون من المفيد أن نجمع هنا أيضًا حلولًا لبناء مشاكل الخادم.

لقد غيرت في "إدارة كود المصدر"> "Git"
قيمة "محدد الفرع" "**" إلى "$ {sha1}"

هذا ما نستخدمه في الوظائف الأخرى أيضًا. هذا يسمح بتشغيل البناء عن طريق الزر (الفروع الافتراضية لإتقانها) أو عن طريق github PR builder (sha1 من الالتزام).

أتذكر ضبط متغير ENV "sha1" على "رئيسي" مرة واحدة. يبدو أنه مفقود الآن ، لكن الوظائف تعمل بشكل جيد ، لذلك دعونا نتجاهل ذلك.

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

مثال على ذلك يمكن أن يحدث فرقًا كبيرًا هو KDB في رأيي.

Namoshek من فضلك فقط انشر مواد البناء _server_ هنا ، وليس حول نظام البناء بشكل عام. مكتبات الكائنات مستخدمة بالفعل للإضافات ، ولكن بالنسبة للمتغيرات المختلفة ، هناك حاجة إلى مكتبات كائنات مختلفة (بسبب علامات المترجم المختلفة). ولكن يرجى الإبلاغ عن الاقتراحات الملموسة كمسألة منفصلة (هل تقصد أدوات kdb؟).

تمت ترقية Jenkins إلى 2.7 ، وتمت ترقية جميع المكونات الإضافية ، وتمت إضافة المكونات الإضافية الموصى بها:

• خط الأنابيب (يبدو أن التثبيت قد فشل؟)
• البرنامج المساعد لمجلد منظمة GitHub

وبعض المكونات الإضافية التي تم إلغاء تثبيتها:

• فرع API
• CVS / SVN (يبدو أنه لم يعد ضروريًا)

بالإضافة إلى ذلك ، تم تثبيت ruby-dev على كل وكيل.

لقد قمت بتحديث "المشكلات الحالية" في أعلى مشاركة. سيكون من المهم أن تقوم Elektra أيضًا بالتجميع بدون أي تبعيات مثبتة ، لذلك يجب أن نتحقق من ذلك مع وكلاء خادم الإنشاء الذي لا يحتوي على أي تبعيات مثبتة (باستثناء cmake و build-basic). وكلاء إنشاء FreeBSD و OpenBSD مهمون أيضًا ؛)

mpranj هل لديك أي فكرة ما هو الخطأ في elektra-multiconfig-gcc47-cmake-options؟ لديهم أخطاء "قاتلة: المرجع ليس شجرة:" أخطاء في كل مكان. لديهم وظيفة "SH1" في التكوين الخاص به؟

لقد صنعتُ التكوينات المتعددة بشكل مستقل عن المجمعين الخرسانيين (هناك ما يكفي من وظائف البناء الأخرى لمجمعين معينين) ، لذلك يجب أن يكونوا قادرين على العمل على أي وكيل.

@ markus2330 ليس لدي فكرة. لم أغير أي شيء وفقط:

• أثار يدويًا بناء من السيد
• تسبب في بناء من جيثب

كان كلا المبنيين قادرين على فحص الشجرة والبدء في البناء.
لذلك: لا يمكنني إعادة إنتاجه.

فكرة واحدة: كان travis يعاني من مشاكل عندما كان هناك علاقات عامة وقم بدمجه قبل أن يقوم travis بالاستنساخ. ربما حدث شيء مشابه مع elektra-multiconfig-gcc47-cmake-options لأن البناء هناك يستغرق حوالي 3 ساعات.

يعمل دفع القطع الأثرية إلى doc.libelektra.org مرة أخرى ، وتمت ترقية Jenkins و Plugins.

لقد قمت بتحديث عنوان URL لخادم الإنشاء الجديد https://build.libelektra.org في Webhooks الخاص بـ github. لذلك نأمل أن يتم بناء العلاقات العامة التالية مرة أخرى.

منزل جنكينز ممتلئ تقريبا. يبدو أيضًا أنه لا يبني علاقات عامة.

منزل جنكينز ممتلئ تقريبا.

شكرا لقد قمت بتغيير حجمها.

يبدو أيضًا أنه لا يبني علاقات عامة.

هل لديك أي فكرة عما يمكن أن يكون خطأ هنا؟ يبدو أن التشغيل اليدوي يعمل؟

نشر docu على doc.libelektra. org: فشل

يبدو أنه يتعذر الوصول إلى vserver لـ * .libelektra.org. أبلغت عنه في هيتزنر.

كان سبب إغلاق اتصال الشبكة من الحاوية هو اختراق موقع libelektra.org. راجع # 1505 لمزيد من المعلومات.

سيكون رائعًا إذا تمكنا من إضافة حزمة git-build-package للتمدد ، فهناك المزيد والمزيد من الأماكن التي تظهر حيث نحتاج إلى حزم دبيان المبنية من أجل الامتداد.

BernhardDenner هل بحثت في المنصب الأعلى؟ هل هناك شيء يمكنك القيام به بسهولة؟ هل هناك شيء يحتاج mpranj إلى مراعاته عند تحسين وظائف بناء الخوادم في المستقبل؟

بناءً على طلب sanssecours ، قمت (مؤقتًا) بتعطيل طلبات elektra-mergere حتى لا تحصل العلاقات العامة دائمًا على خطأ خاطئ. علاوة على ذلك ، أضفت لـ KurtMi

jenkins قم ببناء gcc-config-debian-optimizations من فضلك

KurtMi إذا كنت بحاجة إلى إجراء تغييرات في وظيفة

يمتلكsanssecours الآن حق الوصول إلى خادم

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

تمت إعادة تشغيل sanssecours Jenkins (المرة الثانية). هل يمكنك التوثيق هنا إذا قمت بتثبيت إضافات جديدة. (لا يلزم توثيق التحديثات).

يمكن أيضًا إجراء طلبات إعادة التشغيل هنا.

لقد غيرت "فترة الهدوء" من 2 إلى 5 لإعطاء المزيد من الوقت لدمج العديد من العلاقات العامة و / أو دفع التزامات مختلفة دون إعادة البناء بشكل متكرر.

علاوة على ذلك ، فتحت المشكلة رقم 1689 التي تصف المهلات في البنيات (لم أقم بإضافتها هنا بسبب رسائل الخطأ الطويلة).

لقد نقلت أيضًا بعض المهام القديمة أعلاه في القسم الجديد "مشكلات قديمة / غير ذات صلة [السبب]:".

لقد قمت بتحديث المكونات الإضافية على خادم البناء. نأمل أن تعمل التحديثات على إصلاح المشكلات التي نواجهها في PR # 1698 و PR # 1692.

@ markus2330 هل يمكنك إعادة تشغيل خادم

قمت بترقية Jenkins من 2.73.2 إلى 2.73.3 وأعدت تشغيل Jenkins.

نأمل أن تعمل التحديثات على إصلاح المشكلات التي نواجهها في PR # 1698 و PR # 1692.

قد تكون مشكلة عامة لا تتعلق بهذين العلاقات العامة؟ نأمل أن يتم إصلاحه الآن.

يبدو أن JENKINS_HOME ممتلئ تقريبًا 😢.

@ markus2330 هل يمكنك من فضلك

• قم بتنظيف دليل الصفحة الرئيسية أو أخبرني كيف يمكنني القيام بذلك ،
• تحديث Jenkins وجميع الإضافات التي عفا عليها الزمن؟

شكرا لك على ping لي!

يبدو أن البرنامج المساعد يحتوي على "ثغرة أمنية لقراءة الملف التعسفي" ، وبالتحديد "Script Security Plugin 1.35".

لقد قمت بترقية جميع المكونات الإضافية وقمت أيضًا بترقية jenkins من 2.73.3 إلى 2.89.1.

علاوة على ذلك ، قمت بتغيير حجم القرص من 20 جيجابايت إلى 50 جيجابايت.

يجب إعادة تشغيل الخادم قريبًا ، فهناك بعض العمليات التي لم تتم إعادة تشغيلها والتي قد تتأثر بترقيات المكتبة ، والتي قد تكون غير آمنة في الوقت الحالي (لا تتعلق بـ jenkins ، رغم ذلك). BernhardDenner هل يمكنك إعادة التشغيل (وإجراء الإصلاحات إذا لم يبدأ شيء ما)؟

من فضلك لا تتردد في الإبلاغ عن أي شيء قمت بكسره أثناء هذه الترقيات.

حمل الخادم 20 واستجاب بصعوبة. نحن بحاجة إلى توخي الحذر مع "jenkins build all please" وعلى المدى الطويل يجب علينا نقل الوكلاء بعيدًا عن الخادم الرئيسي.

قمت بالترقية إلى Jenkins 2.89.2 وأعدت تشغيل الخادم. سأبلغ عندما يتم تشغيل كل شيء مرة أخرى.

يبدو أنه تم الآن قطع اتصال كافة الوكلاء بسبب الخطأ "لم يتم قبول مفتاح مضيف الخادم بواسطة رد الاتصال من المدقق".

BernhardDenner رأيت أن تطبيق الدمية قيد التشغيل ، هل تعمل حاليًا على الإعداد؟

حاولت الرجوع إلى الإصدار 2.89.1 و 2.73.3 دون أي نجاح: لا يزال الاتصال بالوكلاء لا يعمل.

شكراً جزيلاً لـ BernhardDenner الذي أصلح مشكلة ssh.

يجب أن نتوقف عن ترقية Jenkins دون قراءة ملاحظات الإصدار ، ويبدو أنه حتى التحديثات المستقرة تكسر الكثير من الأشياء. (لا يمكن التراجع عن ذلك حتى عن طريق خفض التصنيف!)

يجب أن أبلغ عن عنق الزجاجة الرئيسي في خادم الإنشاء.
يستغرق elektra-multiconfig-gcc47-cmake-options ساعة و
يستغرق elektra-multiconfig-gcc-stable 4 ساعات.
لست متأكدًا مما إذا كان هذا سلوكًا جديدًا وأنا أدرك أن هذه الوظائف ليست وظيفة بناء واحدة ، لكن هذا الاختناق لا ينبغي أن يلاحظه أحد.

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

يبدو أن a7.complang.tuwien.ac.at (ryzen) قد تعطل. لقد أبلغت عن المشكلة. نأمل أن يقوم مسؤولنا بإعادة تشغيل الكمبيوتر يوم الاثنين.

لقد قمت بتعطيل التدريجي مؤقتًا (خطأ غريب ، انظر # 1784) ، أعاد المسؤول تشغيل خادم ryzen ، ثم أعدت تشغيل jenkins (لأن Jenkins لم يتمكن من الاتصال بـ ryzen وكان هناك تراكم ضخم من ryzen builds).

يعمل ryzen الآن مرة أخرى ويبني الأعمال المتراكمة.

كانت الفكرة هي توزيع الوظائف الفرعية لهذه الوظائف على أجهزة ryzen

@ markus2330 لقد لاحظت أن هناك خيارًا يسمى Run each configuration sequentially في إعدادات مصفوفة التكوين لمهمة التهيئة المتعددة. ربما يتم توزيعه تلقائيًا إذا قمنا ببساطة بإلغاء تحديده بحيث يقوم ببناء العديد من خيارات التكوين في وقت واحد ، أو هل جربت هذا بالفعل؟

لا ، لم أجربها ، من فضلك جربها.

@ markus2330 انطلاقًا من قائمة انتظار خادم

لكنني لاحظت أن ryzen لا يبدو أنه يتعامل مع هذه الوظائف. أعتقد أن هذا بسبب تكوينه للتعامل فقط مع الوظائف المطابقة لعلاماتها ولا يبدو أن إنشاءات multiconfig تحدد هذه العلامات بشكل مناسب من النظرة الأولى. لذلك يجب أن نجعل ryzen ينفذ كل ما هو ممكن أو نضع المزيد من العلامات على وظائف البناء. يبدو أن ryzen لا يتعامل مع المهام التي لا تحتوي على أي علامات على الإطلاق.

سأقوم بتطبيقه على دول مجلس التعاون الخليجي بالإضافة إلى ذلك بعد أن نجح في تكوين gcc-stabil-multiconfig

شكرا لك!

لكنني لاحظت أن ryzen لا يبدو أنه يتعامل مع هذه الوظائف.

لا ، إنها لا تفعل لكنها تنفذ بالفعل مجموعة من الوظائف الأخرى. ولكن ربما يمكننا جعل الإصدار 2 للقيام بذلك؟

سأقوم بتطبيقه على دول مجلس التعاون الخليجي المستقرة بالإضافة إلى ذلك

انتهى

ولكن ربما يمكننا جعل الإصدار 2 للقيام بذلك؟

لقد قمت بتكوين الإصدار 2 والآن أنتظر فقط حتى يتم دمج رقم # 1806 PR حتى أتمكن من السماح بمزيد من الإنشاءات عليه أكثر من واحد. اعتقدت أن 8 وظائف يجب أن تكون جيدة بالنسبة لها منذ أن كانت 8 نواة ، مع -j 2 من أجل الاستفادة من SMT أيضًا؟

لإعادة تشغيل حاوية build-v2 في حالة تعطل الإصدار 2 أو إعادة تشغيله ، اكتب ببساطة. لاحظ أن هذا لا يمكن القيام به إلا إذا تم بناء الحاوية بالفعل - اتبع doc / docker / jenkinsnode / README.md للحصول على هذه التعليمات. ثم استخدم هذا الأمر لإعادة التشغيل بعد إنشاء الحاوية ولكنها توقفت:

docker start build-v2

أيضًا ، لإعادة توجيه اتصال ssh لعقدة البناء الجديدة من الإصدار 2 عبر a7 إلى العالم الخارجي ، قمت بإعداد نفق ssh التالي على a7 (تقوم حاوية عامل الإرساء بتعيين منفذ ssh الخاص بها إلى 22222 على الإصدار 2):

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

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

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>

انسخ أول شيئين فقط ، لذا لا تنسخ خوارزمية المفتاح والمفتاح نفسه معلومات المستخدم هذه في النهاية لتكوين ryzen-v2 في جينكينز لمفتاح ssh!

v2 معطلة ، أبلغت المشرف. إنه أمر غريب تمامًا: يعد كل من a7 و v2 جهازًا جديدًا تمامًا والحوادث متكررة جدًا.

يبدو أن الإصدار 2 قد عاد وأعدت تشغيل حاوية البناء هناك. لذلك نأمل أن يكون لدينا الآن تصميمات أسرع مرة أخرى. بالإضافة إلى ذلك ، أضفت elektra-haskell إلى "jenkins build all please" لأنني أرغب في الحصول على تصميمات haskell مستقرة لمدقق الكتابة ، لذا فإن الاختبار يعد إضافة جيدة.

علاوة على ذلك ، أود أن أترك ملاحظة هنا بأننا نريد أيضًا إنشاء عقدة بناء أخرى تهتم ببنيات mm التي تبدو الآن أنها عنق الزجاجة الجديد في الإصدار 2 أيضًا.

أخيرًا ، @ markus2330 أعتقد أن مدقق bashism قد تم بالفعل ، لأن هذا أحد اختباراتنا المعتادة /testscr_check_bashisms.sh .

جميع العقد الخاصة بالتسمية debian-jessie-homepage||homepage ووكيل الإنشاء debian-wheezy-mr غير متصلة حاليًا. إعادة تشغيل عوامل البناء لا يعمل. سيكون من الرائع حقًا أن ينظر شخص ما لديه SSH أو وصول مادي إلى هذه العقد في هذه المشكلة.

أعدت تشغيل vservers لكن إعادة تشغيل الوكلاء داخل jenkins لم ينجح مع الخطأ "لم يتم تضمين كسرة صالحة في الطلب". BernhardDenner هل لديك فكرة؟

يبدو أن الإصدار 2 معطل أيضًا. إذن لدينا 3 عوامل غير وظيفية 😢

v2 عاد ، لكني أتساءل لماذا ينخفض ​​دائمًا؟ هل يمكن أن تكون مرتبطة بعملية البناء لدينا؟

فيما يتعلق بـ "الفتات غير الصالحة" ، رأيت ذلك أيضًا عندما حاولت إعادة تشغيل الوكيل على الإصدار 2 ، ولكن عندما حاولت ذلك مرة أخرى ، نجحت.

v2 عاد ، لكني أتساءل لماذا ينخفض ​​دائمًا؟ هل يمكن أن تكون مرتبطة بعملية البناء لدينا؟

يبدو أنه عطل في النواة / الأجهزة (ولا يعمل sysreq حتى عند توقف الكمبيوتر). قد يؤدي استخدامنا إلى حدوث الخطأ. كان الكمبيوتر يعمل دون أي أخطاء لعدة أشهر ، وبما أننا نستخدمه ، فقد عطلناه بالفعل ثلاث مرات.

لقد قمت بترقية النواة وتطهير خادم X.

فيما يتعلق بـ "الفتات غير الصالحة" ، رأيت ذلك أيضًا عندما حاولت إعادة تشغيل الوكيل على الإصدار 2 ، ولكن عندما حاولت ذلك مرة أخرى ، نجحت.

شكرا لك! تمكنت الآن من بدء وكيل الصفحة الرئيسية مرة أخرى.

علاوة على ذلك ، قمت بتعطيل الوكيل debian-jessie-Min و وظيفة البناء الخاصة به. يجب علينا إنشاء حاويات لرسو السفن لأدنى حد من الوظائف ، لقد أضفت هذه كمهمة.

كما فوجئنا بالأمس ، كان خادم المجتمع معطلاً بسبب تعطله وإعادة توجيه ذاكرة التخزين المؤقت ARP الخاطئة إلى عناوين IP الخاصة بنا إلى خوادم أخرى. بعد إعادة التشغيل ، عمل كل شيء مرة أخرى ، لكن مزامنة الغارة لا تزال جارية. (قد يكون بطيئًا جدًا بسبب الحمل الكبير).

يحتوي خادم المجتمع على حمل شبه ثابت يبلغ 10. في الوقت الحالي هو 13.20 11.29 9.35. يجب علينا حقًا تقليل الوظائف التي تعمل مباشرة على خادم المجتمع ونقل التحميل إلى الإصدار 1. أي متطوعين؟

هناك ترقية لـ Jenkins من 2.89.2 إلى 2.89.4. لسوء الحظ ، لم أجد طريقة سهلة لمشاهدة سجل التغيير (فشل apt-get changelog لأنه حزمة غير رسمية). أي أسباب لعدم القيام بهذا التحديث؟

التغيير المنبع في https://jenkins.io/changelog-stable/
يبدو أن 2.89.4 تحتوي على إصلاحات أمنية.

شكرا لبحثك عنه!

قمت بالترقية إلى Jenkins 2.89.4 وكل شيء يعمل مرة أخرى.

لم يتم تشغيل elektrahomepage بشكل افتراضي بعد إعادة التشغيل ، لقد غيرت ذلك (/ etc / vservers / elektrahomepage / apps / init / mark = افتراضي).

لقد قمت أيضًا بتنشيط وظيفة بناء عامل الاختبار.

v2 معطل ، مرة أخرى: صرخة:

لكن يبدو أن a7 على الأقل مستقر الآن.

لقد قمت بتثبيت clang-format-5.0 على a7 وعلى العقدة الممتدة (debian-stretch-mr).

بالنسبة إلى العلاقات العامة التالية ، يرجى إعادة تنسيقها وفقًا لـ clang-format-5.0.

https://build.libelektra.org/jenkins/job/elektra-clang-asan/ تم تعطيله مؤقتًا.

نحن نحقق حاليًا في الإصدار 2. UEFI من 6.6.17. يبدو أن الحوادث تحدث دائمًا في عطلات نهاية الأسبوع ، فربما يكون هناك حمل أكبر في ذلك الوقت؟ سأحاول تكرار إعداد الإصدار 1 على الإصدار 2.

v1 و v2 يعملان بنفس النواة.

@ e1528532 يبدو أن جسر ssh لم يبدأ وأن الأمر في doc / docker / jenkinsnode / README.md يفشل مع "غير قادر على تحضير السياق: غير قادر على تقييم الروابط الرمزية في مسار Dockerfile: lstat / root / Dockerfile: لا يوجد مثل هذا الملف أو الدليل "ثم" تعذر العثور على الصورة "buildelektra- stretch: الأحدث " محليًا ". هذا يعني أن الإصدار 2 لا يمكن الوصول إليه في الوقت الحالي.

كتب @ 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 ، وهو غير قادر على الاتصال بـ GitHub. لقد غيرت تسمية وظيفة الإنشاء من debian إلى debian-stretch-mr وفقًا لذلك. الآن يبدو أن وظيفة البناء

ryzen ، غير قادر على الاتصال بـ GitHub

يبدو أن إصلاح NetworkManager الخاص بالمسؤول مع "manged = true" لم يعمل بشكل موثوق. بعد إعادة التشغيل ، أصبح "/etc/resolv.conf" رابطًا رمزيًا متدليًا مرة أخرى. لقد أصلحته مرة أخرى ، يجب أن يكون GitHub قابلاً للوصول من ryzen. لا يزال يتعذر الوصول إلى rzyen v2 (جسر ssh مفقود).

تم إصدار Elektra 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>

.

نعم ، تأثرت ليس فقط Jenkins ولكن كل شيء آخر يعمل على هذا الخادم. بالنسبة لي ، فإن الوضع غالبًا ما يكون أيضًا غير مقبول. يبدو أن هناك القليل من ذاكرة الوصول العشوائي. (يتم استخدام مبادلة 2GiG)

قد يكون Jenkins هو السبب ، فهناك العشرات من عمليات Java التي تقود القائمة في htop. لفترة طويلة كان لدينا ما يكفي من ذاكرة الوصول العشوائي ولم يتم استخدام المقايضة إلا بصعوبة ، ولم نتغير كثيرًا (باستثناء ترقية Jenkins وزيادة عدد وظائف البناء).

أقترح التوقف عن استخدام خادم المجتمع كوكيل على الإطلاق. لهذا نحتاج إلى v2 مرة أخرى ولكن يبدو أن @ e1528532 مشغول. يمكننا أيضًا استئجار خادم أفضل ولكن بعد ذلك سنحتاج إلى شخص لديه وقت للترحيل.

@ markus2330 هل يمكنك إعادة تشغيل خادم elektra-todo تفشل.

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

أعدت تشغيل Jenkins و v2. يبدو أن جينكينز يعمل بسلاسة مرة أخرى.

@ e1528532 يبدو أن نفق ssh لا يزال لا يعمل. حتى بعد إعادة تشغيل a7 ، لا يمكن الاتصال بـ v2.

لذلك يجب أن نحصل أولاً على الإصدار الثاني مستقرًا قبل التفكير في وضع أشياء أخرى عليه.

سبب التعطل الرئيسي هو جسر ssh. إذا كان الإصدار 2 يعاني من مشكلات ، فعادة ما تتم إعادة تشغيله في غضون يوم واحد.
لقد قمت الآن بإزالة بقية خادم X ، لذلك آمل أن يكون الإصدار 2 مستقرًا الآن أيضًا. بالنسبة إلى a7 ، بدا أن هذه هي الحيلة (لم تكن إعادة التشغيل ضرورية لبعض الوقت). بدون تحميل على الإصدار 2 (الذي يتطلب جسر ssh) ، لن نعرف على وجه اليقين ما إذا كان مستقرًا أم لا.

ماذا عن تقسيم المناقشات حول الأجهزة (إعادة التشغيل) والبرامج (ترقيات Jenkins)؟

يبدو أن هناك مشكلة في الاتصال بالشبكة بين a7 و v2. v2 قيد التشغيل ولكن ما زلت أحصل على "لا يوجد طريق للاستضافة". يبدو أنني لا أستطيع إصلاحه اليوم.

كانت شبكة v2 معطلة لأن إلغاء تثبيت GNOME أدى أيضًا إلى إلغاء تثبيت مدير الشبكة. لقد أصلحنا الآن الشبكة (باستخدام / etc / network / interfaces) وقمنا بالترقية إلى أحدث BIOS / UEFI. لذلك نأمل أن يصبح كل شيء مستقرًا الآن.

بالمناسبة. هناك جهاز آخر يمكننا استخدامه عبر جسر ssh ... (أجهزة الكمبيوتر)

يبدو أن نفق ssh ما زال لا يعمل. حتى بعد إعادة تشغيل a7 ، لا يمكن الاتصال بـ v2.

نعم هذا لم يكن آلياً. الآن لقد اهتممت بكل شيء. يجب إعادة تشغيل حاوية عامل الإرساء تلقائيًا الآن في حالة إعادة تشغيل الجهاز. لقد قمت على الأقل بضبط علامة --restart على "دائمًا" وفقًا لـ https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode # 37618747

علاوة على ذلك ، قمت بإنشاء مستخدم جديد يسمى "ssh-tunnel-a7-v2" والذي لم يتم تعيين كلمة مرور له على كل من a7 و v2 (لذلك ، تم تعطيل مصادقة كلمة المرور لهذا المستخدم). لقد أنشأت شهادة ssh للمستخدم على a7 وأضفت المفتاح العام الخاص بها إلى المضيفين المعروفين في الإصدار 2. ثم أضفت خدمة systemd إلى /etc/systemd/system/ssh-tunnel-a7-v2.service والتي تفتح نفق ssh تلقائيًا كخدمة systemd وفقًا لـ https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service. لذلك يجب أن يعمل أيضًا عند إعادة تشغيل الخادم أو تعطل اتصال ssh ولم يعد يعتمد عليّ أو على المستخدم الخاص بي. نظرًا لاستخدام الشهادة ، لا يلزم استخدام كلمات مرور للاتصالات.

علاوة على ذلك ، يتم إعادة تشغيل الإصدار 2 بالطبع مع تنشيط هذا التكوين الآلي الجديد. آمل أن ينجو من الانهيار التالي (إذا كان هناك واحد) ، من الناحية النظرية يجب أن يكون ولكننا سنرى.

دائمًا ما تفشل مهمة الإنشاء test-docker ، إذا نفذ Jenkins المهمة على 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)" ، لا يعني ذلك أنه لا يوجد خيار لتقييد الوكيل على الإطلاق.

ربما يمكن القيام بذلك عن طريق DSL. سأسأل لوكاس إذا كان يعرف ماذا يفعل.

أهلا،

كما لاحظ sanssecours أن ryzen v2 لا يحتوي على عامل إرساء مثبت ولكنه يحتوي على علامة عامل التحميل.
تتطلب عمليات التشغيل test-docker أن تحتوي العقد على علامة عامل الإرساء.

الحلول الممكنة هي إما تثبيت عامل إرساء على العقدة أو إزالة العلامة من العقدة في جينكينز

الحلول الممكنة هي إما تثبيت عامل إرساء على العقدة أو إزالة العلامة من العقدة في جينكينز

شكرا لك لتقديم حل للمشكلة. لقد قمت للتو بإزالة علامة docker من ryzen v2 . بقدر ما أستطيع أن أقول كل شيء يبدو أنه يعمل الآن.

لقد قمت بتحديث وصف عقدة 'ryzen v2' ليعكس أنها في الواقع عبارة عن حاوية عامل ميناء تعمل على الإصدار 2. ولهذا السبب لم يكن عامل الإرساء متاحًا على الرغم من تثبيته على الإصدار v2.

وأضاف أيضا المساعد لجنكينز الذي يسمح أسهل بناء تصور البيانات (وليس الحاجة إلى النقر في كل بناء)

v2 معطلة مرة أخرى ، أبلغت عنه.

أعدت تشغيل الإصدار 2 ولكن لم أتمكن من إعادة الاتصال بالوكيل.

على الأقل تلقينا أخيرًا رسائل خطأ لما حدث قبل الانهيار (بالطبع ليس هناك ما يضمن أن رسائل الخطأ لها أي علاقة بالتعطل):

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 ، مما يعني أن كل شيء يجب أن يكون مفتوحًا. ومع ذلك ، بطريقة ما ، أظهر لي جينكينز عجلة دوارة لا نهائية لسبب ما ، لا مهلة ، لا شيء.

لقد جربت جسر ssh اليدوي كما فعلنا من قبل ، نفس الشيء. أعد تشغيل حاوية عامل الإرساء مرة أخرى ، نفس الشيء. بصراحة ، لست متأكدًا مما هو الخطأ بالضبط الآن بدون رسالة خطأ ، الشيء الوحيد الذي وجدته هو شخص ما لديه على ما يبدو خطأ مماثل (عجلة دوارة ولكن لا توجد رسالة) ولكن لا يوجد حل لذلك بخلاف إعادة تشغيل السيد جنكينز بالكامل العقدة (التي لم أجربها): https://issues.jenkins-ci.org/browse/JENKINS-19465

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

@ markus2330 أراهن أنك اكتشفت هذا بالفعل بنفسك ولكن بحث سريع أظهر لي أن هذا قد يكون مرتبطًا بتكوين c-state: https://bugzilla.kernel.org/show_bug.cgi؟id=196683 ، هناك بعض المقترحات الحلول لذلك

يبدو أن خادم الإنشاء ryzen غير قادر على الاتصال بمستودعنا :

فشل الجلب من https://github.com/ElektraInitiative/libelektra.git

.

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

في 12 مارس 2018 الساعة 17:03 ، كتب René Schwaiger [email protected] :

يبدو أن خادم البناء 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 بشكل خاطئ ولا يقدم معلومات خادم الأسماء المناسبة. بالنسبة للإصدار 2 ، قمنا بإلغاء تثبيت مدير الشبكة ويبدو أن resolv.conf مستقر الآن هناك. لذا فإن أحد الخيارات هو إلغاء تثبيت مدير الشبكة على a7 أيضًا. (واستخدام / etc / network / interfaces) لا يوجد سبب لوجود إعدادات متباينة للنسختين v2 و a7 ، وذلك فقط بسبب الإدارة غير المتقنة.

من الناحية المثالية (على المدى الطويل) ، ندير كلاهما باستخدام Puppet.

https://bugzilla.kernel.org/show_bug.cgi؟id=196683 ، هناك بعض الحلول المقترحة لذلك

يجب تعطيل C6 لكننا سنواصل التحقيق.

لا يبدو أن عامل البناء الجديد "ryzen v2 docker" يحتوي على برنامج D-Bus الخفي يعمل مثل "debian-stabil-mm" .

هل يمكن لشخص ما أن يقوم بتثبيته / بدء تشغيله أو إخباري بالبرنامج النصي الذي يقوم بتكوين خيارات multiconfig-gcc47-cmake-options بحيث يمكنني إضافة مقتطف للتأكد من بدء تشغيله؟

@ markus2330 أظن أنه نظرًا لتمكين كل من ifupdown و networkmanager ، فإن كلاهما يدخل في شعر الآخر. من المؤكد أن تعطيل أحدهما سيساعد.

حسنًا ، لقد قمت بإزالة جنوم ومدير الشبكة على a7 ليكون متوافقًا مع الإصدار 2.

لا يبدو أن عامل البناء الجديد "ryzen v2 docker" يحتوي على برنامج D-Bus الخفي يعمل مثل "debian-stabil-mm".

يعيش وكيل الإنشاء داخل حاوية عامل يساعدكingwinlu أو @ e1528532 في بدء تشغيل dbus daemon هناك.

شكرا لك. يجب أن يكون سهلًا إلى حد ما. أبدأه في حاوية عامل التحميل (Ubuntu 17.10 مبني من docs/docker/Dockerfile ) بالأوامر التالية:

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

خادم البناء ryzen غير قادر على الاتصال بمستودعنا مرة أخرى 😭.

آسف خطأي. يبدو أن إيقاف مدير الشبكة كان كافياً لكسر النظام.

يجب أن يتم إصلاحه الآن. من فضلك لا تتردد في الإبلاغ عن أي مشاكل أخرى.

@ markus2330 متأكد من أنه

أخذت حريتي لإعادة ملف / etc / network / interfaces (ونقل تكوين الواجهات إلى /etc/network/interfaces.d)
التي تقترن بإلغاء تثبيت مدير الشبكة يجب أن تحافظ على استقرارها

يرجى مراجعة التكوين وربما تشغيل إعادة التشغيل لمعرفة ما إذا كان يعمل

ingwinlu شكرًا لك على الإصلاح ، عملت إعادة التشغيل بشكل جيد.

اكتشفت أنني أزلت عددًا كبيرًا جدًا من الحزم ، لذلك قمت بتثبيت Java (openjdk 9 بدون رأس و default-jre) مرة أخرى: ابتسامة:

ingwinlu هل يمكنك تشغيل dbus على وكيل v2؟ من الناحية المثالية ، يرجى أيضًا نقل "/ home / armin / buildelektra-stretch / Dockerfile" إلى وجهة معينة غير مستخدم.

@ markus2330 يتنبأ اقتراحي حول كيفية المضي قدمًا في بيئة البناء بإزالة عقدة dockercontainer-on-v2 الحالية واستبدالها بواحد قادر على الرصيف (أي لم يعد يشير إلى حاوية عامل إرساء على الإصدار 2 ولكن يشير مباشرةً إلى الإصدار 2) .

بعد ذلك ، يمكننا إعداد خط أنابيب البناء لبناء الصورة نفسها من Dockerfiles التي تم تسجيلها في المستودع لتوفير البيئات المختلفة اللازمة للاختبارات.

يمكنني إعطاء الأولوية لطرح صورة عامل إرساء قادر على dbus عندما أصل إليها ، لكني لا أرغب في القيام بعمل سيكون غير ذي صلة قريبًا إذا لم أضطر إلى ذلك.

نعم ، هذا منطقي!

الهدف طويل المدى لـ v2 هو أنه يتعين علينا مشاركته مع بعض حاويات الإرساء الأخرى (وليس لـ Elektra) ، لذلك سيكون أمرًا جيدًا إذا كانت جميع أجزائنا افتراضية بطريقة لا يمكنها التأثير على حاويات عامل الإرساء الأخرى. (ربما عامل إرساء متكرر أو Xen؟) يمكننا / يجب أن نفعل الشيء نفسه بالنسبة لـ a7 للحصول على إعدادات متطابقة.

سنستمر في الوصول مباشرة إلى الأجهزة ولكن يجب علينا تقليل أي خطر يتمثل في أن Jenkins يمكن أن تقتل آلات Docker التي لا علاقة لها بها.

بالنسبة لبعض الوكلاء ، لدينا بالفعل إعداد الدمى. سيكون رائعًا إذا لم نتجاوزه أو حتى أفضل: تمديد هذا الإعداد لـ a7 و v2. آمل أن يتمكن BernhardDenner من تزويدك بمزيد من المعلومات حول ذلك قريبًا.

خادم البناء معطل مرة أخرى 🙌.

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

نعم ، الخادم بأكمله معطل ، بما في ذلك خادم الإنشاء: cry: و v2 معطل أيضًا (بشكل مستقل). أعدت تشغيل الإصدار 2 وغيرت خيار C-States في UEFI. ولكن يبدو أن هناك مشكلة كبيرة في الخادم الخاص بنا. نأمل أن نستبدلها بأجهزة أفضل ذات ذاكرة أكبر: crossed_fingers:

مناقشة فريق GitHub

لم يتم إخطار كل من ElektraDevelopers إذا كتبنا شيئًا ما في مناقشة فريق GitHub؟ هنا في هذا العدد ، يمكن للجميع تحديد ما إذا كان يريد الاشتراك.

بالنسبة لي ، فإن السؤال الذي لا يزال مفتوحًا هو ما إذا كان يجب علينا تقسيم هذه المشكلة إلى مسألتين: الأجهزة ذات الصلة و Jenkins ذات الصلة.

لم يتم إخطار كل من ElektraDevelopers إذا كتبنا شيئًا ما في مناقشة فريق GitHub؟

بقدر ما أستطيع أن أقول ، نعم.

هنا في هذا العدد ، يمكن للجميع تحديد ما إذا كان يريد الاشتراك.

هذا صحيح أيضًا بالنسبة لمناقشات الفريق .

خادم البناء يعمل مرة أخرى. تم تغيير الإعدادات:

• xms و xmx لتقليل كمية المجموعة المهملة عند وجود الكثير من البنيات في قائمة الانتظار
• لقد لاحظت أننا نستخدم الاقتراع SCM. لقد قمت بخنق جهاز الاستطلاع إلى 4 استطلاعات متزامنة على مستوى العالم في وقت واحد على أمل تقليل قليلاً من الارتفاعات التي يحصل عليها الخادم حاليًا.

تعديل:

* قم بتعيين رقم البنية للاحتفاظ بـ 30 لجميع خطوط الأنابيب وفقًا لمصادر متعددة يتم قراءتها عند الوصول إلى webui وبالتالي يؤدي عدد كبير من الإنشاءات القديمة إلى إبطاء الطلبات

قم بتحديث Jenkins إلى الإصدار. 2.107.1

• تحديث ملف جنكينز الحربي
• قم بتعطيل إعداد أمان المكون الإضافي Use browser for metadata download لأنه لن يسمح بتحديث المكونات الإضافية
• قم بتحديث الإضافات إلى أحدث الإصدارات المتاحة

تحرير 2018-03-18:

• تمت إضافة المنفذ الثاني لجميع العقد التي تعمل على مم

* خفضت أولويات جميع الوكلاء الذين يعملون على السيد

يجب أن يكون المعلم أكثر استجابة الآن تحت الحمل. يجب أن يكون بناء كل شيء أقرب إلى ساعتين مقارنة بـ 4 ساعات + من قبل.

تحرير 2018-03-24:
آسف على التأخير ، أسبوع حافل ...

• تمت إضافة وظيفة جديدة إلى jenkinsserver (elektra-jenkinsfile) والتي ستقوم بتشغيل ملف Jenkins الموجود في الريبو (بمجرد وجوده)

تحرير 2018-03-28:

• أعد تشكيل ملف وحدة النفق ، والآن يوزع ملفات البيئة وبالتالي يمكن تعديله للإشارة إلى أهداف متعددة
• تمت إضافة خادم v2 باعتباره تابعًا قادرًا على تشغيل عامل الإرساء
  
  
  
  • أضاف مستخدم jenkins على الإصدار 2
  
  
  • تم تثبيت openjdk-9 على الإصدار 2.0
  
  

تحرير 2018-03-29:

• إصلاح إعدادات ulimit على jenkins master

على الرغم من أنني متأكد تمامًا من أن 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 في الوقت الحالي لأنه من الواضح أنه لا يمكن العثور على صور الإنشاء المطلوبة لتشغيل الاختبارات.

لكن اللعنة على هذا الشيء سريعًا إذا حصل بالفعل على شيء يمكنه بناؤه
// EDIT3: إعادة تجديد عامل ميناء الاختبار للتشغيل فقط على العقد مع علامة عامل الإرساء الجاهزة وأعطت هذه العلامة إلى ryzen

للأسف ، يبدو أن المشكلة أكبر مما كان متوقعًا في الأصل.

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

أدى إدخال عقدة جديدة (ryzen v2 أصلي) إلى تشويش التخصيص قليلاً على الرغم من أنه لا ينبغي أن يكون كذلك.

يرجى توقع حدوث سلوك غير متوقع حتى يتم تشغيل كل شيء حيث كان مرة أخرى.

التغيير:

• العقد التي تمت إعادة تسميتها ، <os>-<hostname>-<buildenv>
• تعطيل elektra-multiconfig-gcc47-cmake-options
  في الواقع لم يتم تشغيله على العبيد gcc47 لبعض الوقت الآن ، مع مزيج من مبنى gcc49 أو gcc63 اعتمادًا على المكان الذي تم تحديده. إذا تم إعادة تجديده ، فمن المحتمل أن ينتقل إلى حاوية dockercontainer الممكّنة من مجلس التعاون الخليجي 63 على الإصدار 2
• تراجعت عن الكثير من الوظائف (ربما فاتها بعض منها)
  
  
  
  • كانت elektra-todo تتطلب stable ، لكن ليس كل العقد المستقرة تحتوي بالفعل على sloccount مثبتة
  
  
  • العديد من الحالات المماثلة
  
  

يبدو أن A7 قد انخفض

waht [email protected] schrieb am Do.، 29. März 2018 ، 21:24:

على الرغم من أنني متأكد تمامًا من ingwinlu https://github.com/ingwinlu أو
شخص ما موجود بالفعل على هذا: يبدو أن ryzen v2 تم تكوينه بشكل خاطئ:

FATAL: تعذر تطبيق العلامة jenkins-BUILD_FULL = ON ، BUILD_SHARED = ON ، BUILD_STATIC = ON ، ENABLE_DEBUG = ON ، ENABLE_LOGGER = ON-185
hudson.plugins.git.GitException: الأمر "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" تم إرجاع رمز الحالة 128 :
stdout:
ستدير:
* من فضلك قل لي من أنت.

يركض

git config - global user.email " [email protected] "
git config --global user.name "اسمك"

لتعيين الهوية الافتراضية لحسابك.
احذف - global لتعيين الهوية فقط في هذا المستودع.

فادح: اسم معرف فارغ (لـ

من عند
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
.

هل تريد العمل عليه؟ يمكنني إعادة تشغيله اليوم. كبديل لمسؤولنا أو يمكنني إعادة تشغيله يوم الثلاثاء.

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

markus2330 [email protected] schrieb am Sa. ، 31. März 2018 ، 14:33:

هل تريد العمل عليه؟ يمكنني إعادة تشغيله اليوم. كبديل لدينا
المشرف أو يمكنني إعادة تشغيله يوم الثلاثاء.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

حسنًا ، لقد أعدت تشغيله وقمت أيضًا بتعطيل C6-State في BIOS / UEFI (تم تمكينه). لقد قمت أيضًا بإزالة gnome / xorg (اعتقدت أنني فعلت ذلك بالفعل؟).

بالمناسبة. كانت الشاشة سوداء تمامًا ، لذا لا يمكننا إلا تخمين السبب.

لقد ظهرت على a7 كل 10 دقائق أو نحو ذلك:

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 latelty

قسم valgrind المعطل في elektra-ini-mergerequests حيث تم تشغيله عبر make run_memcheck

هذه كانت تظهر على a7 كل 10 دقائق أو نحو ذلك

نعم ، لقد رأيناهم بالفعل. عندما تم شراء الكمبيوتر ، قام شخص ما بالتحقق مما إذا كانت ECC تعمل ولم تحدث مثل هذه الأخطاء في ذلك الوقت. هل تواتر هذه الأخطاء يعتمد بطريقة ما على حمل النظام؟

قسم Valgrind المعطل في أسئلة elektra-ini-mergere كما تم تشغيله عبر make run_memcheck

شكرا لتنظيف هذا.

أواجه مخارج عشوائية (حاويات تتعطل ، أبنية تتوقف في المنتصف ، قطع الاتصال ، ...) على 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 مرة أخرى.

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

على جبهة أكثر إنتاجية: لقد قمت بتثبيت الواجهة الأمامية للمحيط الأزرق على جينكينز. معاينة

تبدو رائعة! ربما يمكنك إظهاره لنا في الاجتماع القادم؟

مشرفنا بالفعل في عطلة نهاية الأسبوع. سأعيد تشغيل a7 وأعيد تعيين BIOS / UEFI إلى إعدادات المصنع الافتراضية. إذا استمرت الأخطاء خلال عطلة نهاية الأسبوع ، فمن المأمول أن يقوم بتبادل ذاكرة الوصول العشوائي.

تحرير: لم تكن هناك مهمة بناء قيد التشغيل ، وبالتالي لم يتم إلغاء أي مهمة بناء.

تحرير: كل شيء عاد مرة أخرى. لا توجد أخطاء في الذاكرة حتى الآن.

تبدو أفضل بكثير. هل شاهد شخص ما الكثير من النصائح التقنية الخاصة بـ Linus وقام برفع تردد التشغيل عن الخادم؟

آسف ، كان علي إيقاف جينكينز لبعض الوقت. كان الخادم يحمل 20 حمولة ولم تعد الأشياء التي كنت بحاجة إلى القيام بها ممكنة بعد الآن (> وقت انتظار لمدة ساعة واحدة ، ثم استسلمت وأوقفت جينكينز).

هل من الممكن أنه حتى وظائف البناء التي لم تبدأ بعد تحتاج إلى ذاكرة وصول عشوائي؟ (كانت قائمة الانتظار طويلة جدًا) وإلا فإن وظائف البناء المحلية هي أفضل مرشح لهذه المشاكل. (تم تشغيل 3 وظائف بناء محلية)

ingwinlu من الناحية المثالية ، نحن لا نبني أي شيء على هذا الخادم. علاوة على ذلك ، هل يمكننا إنشاء وظائف تعتمد على الحمل على الخادم. (لا تبدأ المهام على الخادم مع تحميل> 5؟).

لقد بدأت كل شيء مرة أخرى ولكن آمل أن نجد حلاً سريعًا لذلك.

لقد قمت بضخ VERSION و CMPVERSION في إعدادات نظام Jenkins.

ingwinlu سيكون رائعًا إذا كانت لدينا هذه الإعدادات أيضًا داخل Jenkinsfile.

@ markus2330 انظر 8de9272051fe903a7df08f0abdf18879701f7ac9 للحصول على مثال حول كيفية تحقيق ذلك في ملف Jenkins

تمت إزالة make run_memcheck من الأهداف التالية بسبب فشلها منذ بعض الوقت وظهورها أخيرًا في نظام الإنشاء بفضل # 1882

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

تقييد elektra-gcc-configure-debian-stretch للتشغيل على العقد: stretch && !mr

قم بتحديث jenkins master إلى ver. 2.107.2 + قم بتحديث كافة المكونات الإضافية

حاولت إضافة allowMembersOfWhitelistedOrgsAsAdmin لجميع وظائف الإنشاء اليوم ولكن يبدو أنه لا يمكنني تشغيل جميع الإنشاءات (انظر # 1863) بشكل صحيح ويتم تنفيذ بعض الوظائف فقط

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

هل يمكن لشخص ما من فضلك

• يصلح
• تعطيل أو
• (أفضل) حذف

elektra-clang-asan فضلك 🙏. حاليًا ، فشلت وظيفة البناء على الرغم من جميع الاختبارات الفاشلة:

• testlib_notification
• الاختبارات
• الاختبارات
• الاختبارات
• الاختبارات
• الاختبارات
• الاختبارات

تعمل بشكل جيد على ترافيس .

لا يختبرون نفس (على سبيل المثال) يستخدمون إصدارات مختلفة من رنة ...

نظرًا لأن هذا الموضوع غير قابل للتتبع تمامًا لتقارير الأخطاء أو المناقشات الأطول ، فسوف أفتح مشكلات جديدة لـ clang و clang-asan بمجرد الوصول إليها.

لا يختبرون نفس (على سبيل المثال) يستخدمون إصدارات مختلفة من رنة ...

أوافق ، بينما يستخدم Travis clang 5.0.0 القديم ، فإن إصدار Clang على elektra-clang-asan قديم ( 3.8.1 ). لا أرى قيمة وظيفة إنشاء ASAN الممكّنة لمثل هذا المترجم القديم.

لقد أنشأت رقم 1919 لاختبار "testlib_notification" الفاشل على "elektra-clang-asan".

لقد اختبرت تصميمًا جميعًا مع تعطيل جميع وكلاء السيد وكان السيد مستجيبًا تمامًا بينما تم تمكين جميع الإنشاءات مع جميع وكلاء السيد في الواقع من انتهاء بعض البنيات. ومن ثم فإن # 1866 سيوفر بالتأكيد تحسينًا إذا تمكنا من التخلص من جميع وكلاء السيد (- مهم لأنه غير قابل للتخزين في حاويات)

يظهر المزيد من الاختبارات أنه إلى حد كبير فقط الصفحة الرئيسية تبني الوظيفة. لقد أزلته من build all في الوقت الحالي ، لذا لا يتم تشغيله إلا بشكل صريح.

سيتم استبداله بمحلول في حاويات.

v2 متصل بالإنترنت مرة أخرى باستخدام أحدث BIOS.

يرجى الإبلاغ عن أي نتائج هنا (قد تكون وحدة المعالجة المركزية عربات التي تجرها الدواب).

يبدو أن a7 قد انخفض؟

في 4 مايو 2018 الساعة 11:10 ، كتب markus2330 [email protected] :

v2 متصل بالإنترنت مرة أخرى باستخدام أحدث BIOS.

يرجى الإبلاغ عن أي نتائج هنا (قد تكون وحدة المعالجة المركزية عربات التي تجرها الدواب).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 يدويًا اليوم. يبدو أن الإصدار 2 لا يمكن الوصول إليه بعد الآن. هل يمكنك إرضاء أنها تعمل بالفعل؟

// EDIT: تم حلها عن طريق تحديد تكوين الشبكة على كلا الجهازين

يبدو أن 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

يمكن أن يكون أي شيء. من وحدة المعالجة المركزية ryzen الخاطئة إلى psu سيئة :(

في 12 مايو 2018 الساعة 14:33 ، كتب markus2330 [email protected] :

يجب أن يكون كل شيء جاهزًا ويعمل الآن.

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

كانت السجلات:

معلومات: rcu_sched الكشف عن الأكشاك على وحدات المعالجة المركزية / المهام:
...
rcu_sched kthread يتضور جوعا مقابل 7770 jiffies
الوكالة الدولية للطاقة: BUG soft lockup - CPU # 2 عالقة لمدة 22 ثانية! [عامل عامل]
... (العديد من التكرارات)
NMI watchdog: اكتشفت Watchdog وجود LOCKUP صعبًا على وحدة المعالجة المركزية 2

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

حول # 1993

ingwinlu يرجى تعطيل الوظائف إذا لم تنجح حاليًا (أو على الأقل لا تقم

إذا فشلوا بسبب بعض إجراءات Jenkins التي قمت بها ، فستكون إعادة تشغيل الوظائف أمرًا رائعًا: القلب: قول ذلك هنا في رقم 160 أمر جيد أيضًا.

v2 يعمل مرة أخرى ، مع وحدة المعالجة المركزية الجديدة!

يرجى تقديم العديد من الوظائف لاختبار الإجهاد: ابتسم:

يبدو أن a7 أسفل مرة أخرى.

شكرا لك ، كل شيء عاد مرة أخرى.

أعدت تشغيل a7 مرة أخرى.

من المرجح أن يؤدي وجود دائرة تعيد تعيين a7 كل ساعة إلى زيادة التوفر.

متى نتوقع عودة a7 إلى الإنترنت مرة أخرى؟

a7 عاد عبر الإنترنت

تم إعادة اتصال v2 بالإنترنت

سيتم تبادل مصدر الطاقة الخاص بـ v2 في حوالي ساعة واحدة.

ingwinlu هل يمكنك تعطيل الوكلاء وتمكينهم مرة أخرى بعد ذلك؟ (إذا كنت تعمل عليه حاليًا.)

تم تعطيل وكلاء الإصدار 2 في الوقت الحالي

v2 يعمل مرة أخرى. لديها مصدر طاقة جديد. يرجى إرسال العديد من الوظائف لاختبار التحمل على الجهاز.

لقد قمت بتحديث ملحقات جنكينز. أدت عملية إعادة التشغيل الناتجة جزئيًا إلى استعادة عُقد jenkins القديمة (قبل إعادة تسميتها) مما أدى إلى تداعيات معطلة في كل مكان حيث تم كسر مستودعات git.

قمت بتنظيف المستودعات المتأثرة وتنظيف حاويات عامل التخزين المؤقت فقط للتأكد.

a7 معطل مرة أخرى وعلى هذا النحو لا تتوفر البنيات القائمة على عامل الإرساء مرة أخرى.

أقوم أيضًا بإرجاع التحديث إلى xunit لأنه ينتهك القيود الأمنية.

أعدت تشغيل a7 وأعدت توصيل جميع الوكلاء.

لا تتوفر تصميمات عامل الإرساء لأن a7 معطل مرة أخرى.

أعدت تشغيل الخادم وأعدت توصيل الوكلاء.

أعتقد أن استبدال a7 هو أفضل طريقة للمضي قدمًا ، انظر # 2020

أعتقد أنه قد تم إيقافه مرة أخرى ، فقد أدى التزامي الأخير إلى Cannot contact a7-debian-stretch: java.lang.InterruptException

@ e1528532 شكرا لك على كتابته هنا! إذا كنت تريد ، يمكنك أيضًا التصويت في # 2020

أعدت تشغيل a7 وأعدت الاتصال بالوكلاء.
دعونا نأمل في الأفضل ألا تحدث مشاكل خلال عطلة نهاية الأسبوع.

A7 هو أسفل مرة أخرى: صرخة: من المستغرب أن عملت تقريبا في نهاية الأسبوع كله. قد يكون سجل الجهوزية للأسبوع. ومع ذلك ، لم تحصل # 2020 على الكثير من التعليقات.

أعدت تشغيل a7 (كان رد فعل على sysctl) وبدأ شخص آخر جينكينز. كل شيء يعمل مرة أخرى.

a7 نزل مرة أخرى.

شكرا لك على المعلومات! أعدت تشغيل a7 وأعدت الاتصال بالوكلاء.

هل يعقل أن لدينا الوكيل "debian-jessie-minis"؟ أعتقد أنه يمكنك إزالته بأمان بمجرد دمجه في Docker. (ويبدو أنه كذلك بالفعل)

تعديل:
في 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 انخفض أيضًا.

تحرير: لكن يبدو أنني قادر على الاتصال به عبر ssh ....
EDIT2: أصدر إعادة تشغيل على الإصدار 2 ولكن الآن لم يعد بإمكاني الاتصال. لا يزال pingable من a7 على الرغم من ...

EDIT3: الآن a7 معطل أيضًا.

شكرا على الإبلاغ! أعدت تشغيل a7 و v2. يجب أن نعيد النظر في # 2020.

أعتقد أن الإصدار 2 معطل مرة أخرى:

لا يمكن الاتصال بـ v2-debian-stretch: java.lang.InterruptException

مع الإصدار 2 ، كان كل شيء على ما يرام ولكن a7 كان معطلاً مرة أخرى. جميع الوكلاء متصلون الآن مرة أخرى.

يبدو أن الإصدار 2 شبه لا يستجيب مرة أخرى. يمكن اختبار الاتصال من a7 ولكن لا يوجد عمل ssh على الإطلاق. يجب أن تكون قضايا btrfs من sympthoms وحدها. هل يمكنك إعادة تشغيل كل شيء قبل العودة إلى المنزل لقضاء عطلة نهاية الأسبوع؟

ingwinlu شكرًا لك ، أعدنا تشغيل v2 مع

عملت ssh فقط عند عدم الاتصال عبر الجسر.

بعد إعادة تشغيل خدمة التجسير ، يمكن إنشاء الاتصال.

يبدو أن نفق ssh انتهى به الأمر في حالة غريبة غير محددة ولم يقتل نفسه. لست متأكدا لماذا لم تقتل نفسها (serveraliveinterval قيد التشغيل).

كنت بحاجة أيضًا إلى تنظيف جميع مساحات العمل يدويًا على الإصدار 2 نظرًا لتلف fs وفشلت جميع وظائف الإنشاء عليها.

يبدو أن a7 قد انخفض. لست متأكدًا مما إذا كان بإمكاني إعادة تشغيله قبل يوم الاثنين.

أعدت تشغيل a7 و v2. (v2 نظرًا لوجود رسائل خطأ على a7 تفيد بأنه لا يمكنه إنشاء جسر ssh إلى الإصدار 2. ولكن أيضًا بعد إعادة تشغيل الإصدار 2 حدثت نفس رسائل الخطأ. ومع ذلك ، يبدو أن جسر ssh يعمل. ربما تكون بعض التبعية (الشبكة؟) مفقودة في البرامج النصية التمهيد a7؟)

ربما بعض التبعية (الشبكة؟) مفقودة في البرامج النصية التمهيدية لـ a7

لا هو هناك.

لا يمكن إنشاء جسر ssh إلى v2

أعتقد أن هذا السلوك يحدث عندما تبدأ نواة v2 في عدم الاستجابة (وبالتالي لا يمكن إنشاء اتصالات شبكة واردة). لقد ذكرت في الماضي السجلات التي تشير إلى أخطاء btrfs في الإصدار 2.

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

عادت a7 و v2 مرة أخرى (a7 مع وحدة المعالجة المركزية الجديدة ، v2 مع فحص نظام ملفات الجذر)

بينما استمر في العمل خلال اليوم (مع بنية متسقة) يبدو أن a7 نزل مرة أخرى.

نعم ، سأعاود العمل صباح الغد.

يجب أن نناقش مرة أخرى # 2020.

أعدت تشغيل a7. كان مرة أخرى توقف وحدة المعالجة المركزية.

a7 أسفل مرة أخرى.

شكرا لك ، لقد أعدت تشغيله. جميع الوكلاء متصلون بالإنترنت مرة أخرى.

يبدو أن بعض عُقد دبيان معطلة ، وبالتالي فإن عددًا قليلاً من PRS ينتظر وقتًا طويلاً لبدء تنفيذ الاختبار. هل هذا مقصود؟

يبدو أن بعض عُقد دبيان معطلة ، وبالتالي فإن عددًا قليلاً من PRS ينتظر وقتًا طويلاً لبدء تنفيذ الاختبار. هل هذا مقصود؟

أثناء الترقية على العقدة غير المستقرة mm-debian ، أصبحت الآلة غير مستجيبة ولم نتمكن من الاتصال بها منذ ذلك الحين. نظرًا لأن المالك لا يرد على رسائل البريد الإلكتروني الخاصة بنا ، فمن المحتمل أن يختفي إلى الأبد.

على الرغم من أننا نقلنا قدرًا جيدًا من وظائف الإنشاء إلى النظام الجديد ، فإن الوظائف المفقودة هي تلك التي يتم تعليقها حاليًا في قائمة الانتظار.

لقد عطلت الوظائف المتأثرة ووضعتها على أنها سيتم استبدالها + إزالتها من المستندات

ingwinlu شكرا لك على الاهتمام بهذا!

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

هذه المرة v2 هو الفائز المحظوظ.

@ markus2330 قمت بتنظيف أعلى وظيفة.

شكرا لك على التنظيف! سأعيد تشغيل الإصدار 2 (وربما a7 ، دعونا نرى) غدًا في الصباح.

أعدت تشغيله. لم يكن هناك رد فعل ولا رسالة. انظر # 2020

يرجى إعادة تشغيل a7 و v2.

أعيد تشغيل a7. لم أجد أي مشكلة في الإصدار 2 ، فهل يجب إعادة تشغيله على أي حال؟

يتوفر i7 الآن على 192.168.173.96 ، هل يمكنك إنشاء جسر عبر a7 إليه؟

تحتاج إلى إنشاء مستخدم ssh-tunnel-a7-v2 على الجهاز أو إنشاء حساب لي.

أضفنا إنشاء تابع إضافي i7-debian-stretch سيساعد في إنشاء وظائف libelektra .

v2-docker-buildelektra-stretch (offline) حيث لم تتم جدولة المزيد من وظائف البناء هناك. تم أيضًا تعطيل جسر ssh على a7 الذي كشف العامل.

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

سيكون خادم البناء الخاص بنا v2 غير متصل بالإنترنت حتى 31.07 09:00 لأننا نجري معايير عليه. توقع أوقات بناء أطول.

نأسف للإزعاج.

// تحرير: وقت تعطل ممتد بمقدار ساعتين

يبدو أن التمديد مر الآن أيضًا. سيكون من الجيد استعادة البنيات السريعة بعد الغداء (حوالي الساعة 13:00). :ابتسامة:

تمت ترقية mm-debian-unstable وإعادة الاتصال بالإنترنت. هل هناك وظائف يمكننا إعادة تنشيطها وتثبيتها على الخادم؟

يبدو أن قرص i7 ممتلئ. وظيفتي تفشل مع No space left on device ( الوظيفة والوظيفة )

أنا حقا أحب واجهة البناء الجديدة (dockerization & jenkinsfile) بالمناسبة. مفيد جدًا في إعادة إنتاج أخطاء البناء.

شكرا على الإبلاغ!

لسوء الحظ ، سيتطلب تغيير الحجم إعادة التشغيل (يجب تصغير الجذر قبل أن يتم تمديد الآخر) وسيجلب 20 جيجا فقط. لقد قمت بإزالة مجلدات بناء Jenkins لكنها كانت صغيرة ، لذلك ما زلنا 99٪.

لذا فإن تنظيف حوض الرصيف سيكون أكثر فعالية:
ingwinlu يبدو أن كلا من _docker / overlay2 ضخم. أي فكرة لماذا تم جمع كل هذه الأشياء هناك؟

أقوم بإجبار أدوات عامل الإرساء التي تم تنظيفها باستخدام docker system prune -fa . هذه
تنظيف حوالي 190 جيجابايت من المساحة المستخدمة في صور عامل الإرساء.

في يوم الاثنين ، 13 أغسطس 2018 الساعة 07:54 ، كتب markus2330 [email protected] :

شكرا على الإبلاغ!

لسوء الحظ ، سيتطلب تغيير الحجم إعادة التشغيل (يجب عمل ملفات rootf
أصغر قبل أن يتم تمديد الآخر) وسيجلب فقط 20G. أنا
أزلت مجلدات بناء Jenkins لكنها كانت صغيرة ، لذلك ما زلنا في
99٪.

لذا فإن تنظيف حوض الرصيف سيكون أكثر فعالية:
يبدو أن 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
.

شكرا لك!

هل يمكننا وضع هذا في libelektra-daily أو في cronjob؟

يوميا يفعل شيئا مشابها ولكن أقل عدوانية. يجب أن تأخذ آخر
انظر عندما أعود إلى فيينا.

markus2330 [email protected] schrieb am Mo. ، 13. أغسطس 2018 ، 09:22:

شكرا لك!

هل يمكننا وضع هذا في libelektra-daily أو في cronjob؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 في صورة sid الخاصة بنا أثناء اختبارات debian-unstable-full-clang ولكن فقط عند تنفيذها على الإصدار 2. قمت بتحديث الصورة يدويًا لاستخدام أحدث الحزم المتاحة ودفعتها إلى التسجيل الخاص بنا.

تم اجتياز https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ ، ولكننا سنراقبها.

وقد ورد ذكر هذه المسألة في # 2216 و # 2215 (sanssecoursmpranj).

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

اسمحوا لي أن أعرف إذا كان هناك شيء لا يعمل كما هو متوقع.

// EDIT يبدو كما لو أن الدفع لا يعمل على الرغم من نجاح تسجيل الدخول.
// تم تعطيل الوصول العام EDIT2 مرة أخرى. https://github.com/moby/moby/issues/18569. استعادة الوظائف لبناء النظام
// EDIT3: عاد الريبو العام مرة أخرى في hub-public.libelektra.org

يريد أنطون استبدال اللوحة الرئيسية للكمبيوتر حيث يتم إلغاء تنشيط الترابط التشعبي الثلاثاء أو الأربعاء القادم (يمكننا الاختيار). هل يحتاج شخص ما للخادم في أحد هذين اليومين؟

لقد أعدت تشغيل سجل docker وقمت بتشغيل التنظيف يدويًا. نأمل أن يؤدي ذلك إلى حل أي مشكلات في إنشاء صورة موقع الويب.

ingwinlu أشكركم على أعمال الصيانة!

لسوء الحظ ، فشلت مرحلة WebUI بشكل موثوق تمامًا ، على سبيل المثال 321 أو 320 (فشلت حتى قبل ذلك ولكن أيضًا عند سحب WebUI؟).

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

كحل بديل ، قمت بتعطيل المراحل غير الموثوق بها في c3b59ecef95287ffc33b094b37e03d0ec6b5710f ولكن آمل أن نتمكن من تمكينها قريبًا مرة أخرى!

هل يجب أن يظل a7-debian-stretch غير متصل بالمعايير؟ (تم عدم الاتصال بالإنترنت منذ 21 فبراير 2019 10:47:56 صباحًا)

شكرا على الإبلاغ! يبدو أن أنطون نسي إعادة التنشيط. لقد قمت بتنشيط العقدة مرة أخرى وقمت أيضًا بإزالة العقد القديمة (باستثناء مم لأنها لا تزال تعمل).

كان هناك توقف لخادمنا في الصباح. كل شيء يعمل مرة أخرى لكننا حصلنا على عرض بأنهم سيتبادلون الأجهزة. لذلك على الأرجح سيكون لدينا وقت تعطل آخر لمدة ساعة تقريبًا اليوم.

الخادم يعمل مرة أخرى. لسوء الحظ ، حصلنا على نفس الجهاز. إذا كان لدى شخص ما وقت للتثبيت / الإعداد ، فيمكننا ترقية الجهاز.

يبدو أن تصميمات Jenkins بطيئة جدًا (عدة ساعات لبناء كامل). بقدر ما أستطيع أن أقول ، فقط a7-debian-stretch و i7-debian ينفذون الاختبارات ، بينما جميع العقد الأخرى خاملة. هل هذا سلوك متوقع؟

شكرا للإبلاغ عن هذه المشكلة!

لا ، هذا ليس سلوكًا متوقعًا. يبدو أن الإصدار 2 معطل. سأعيد تشغيله في أسرع وقت ممكن.

يجب أن يعود الإصدار 2 مرة أخرى

الإصدار 2 معطل وأخشى أنه سيبقى هكذا حتى يوم الاثنين. ستكون الأبنية بطيئة جدًا حتى ذلك الحين.

v2 مرة أخرى مع لوحة رئيسية جديدة

سأقوم بترقية جميع وكلاء البناء الثلاثة (i7 ، v2 ، a7 ، بهذا الترتيب) إلى Buster لتجنب # 2852

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

i7-debian-buster ، i7-debian-stretch السابق متصل بالإنترنت مرة أخرى

الإصدار 2 هو التالي

v2-debian-buster و a7-debian buster متصلان بالإنترنت مرة أخرى

أعدت تشغيل وظيفة الإنشاء الناجحة السابقة على المستوى الرئيسي لمعرفة ما إذا كان كل شيء يعمل مرة أخرى:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

علاوة على ذلك ، أضفت العلاقات العامة https://github.com/ElektraInitiative/libelektra/pull/2876 لتمكين وظائف بناء باستر.

يبدو أن الإصدار 2 معطل (فشل اتصال ssh أيضًا) ، لسوء الحظ أنا لست في فيينا. آمل أن يقوم مسؤول النظام لدينا بإصلاحه غدًا.

a7 الآن معطل أيضًا ومعه i7 (المتصل عبر جسر فوق a7).

حتى الآن لا يمكن تنفيذ أي بناء. لقد اتصلت بالمسؤول.

جميع الخوادم تعمل مرة أخرى. يرجى إعادة تشغيل البنيات إما عن طريق دفع التزامات جديدة أو كتابة "jenkins build libelektra please" كتعليق على العلاقات العامة الخاصة بك.

ملاحظة فنية: a7 نزل بسبب "القفل الناعم لعلة حراسة المراقبة". حاولت إضافة "nomodeset nmi_watchdog = 0". دعونا نأمل ألا يكونوا غير مستقرين مرة أخرى كما كانوا بالفعل.

a7 (وكذلك v2 و i7 لأنهما متصلان عبر جسر فوق a7) معطلة. لقد اتصلت بمشرفنا. يرجى محاولة تجنب بدء الإنشاءات الآن ، حيث سيؤدي ذلك إلى إنشاء قائمة انتظار طويلة فقط.

a7 عاد عبر الإنترنت (كان بالفعل بالأمس) ، لم يتأثر الإصدار 2

وفقًا لصفحة حالة خادم الإنشاء ، فإن الخوادم:

• a7-debian-buster ،
• i7-debian-buster و
• v2-debian-buster

إلى أسفل. يبدو أن دليل بيانات Jenkins ممتلئ جدًا أيضًا. وأثناء وجودنا فيه: سيكون أمرًا رائعًا ، إذا تمكنا من ترقية Jenkins ومكوناته الإضافية. أنا مهتم بإصلاح هذه المشاكل. هناك مشكلتان بالرغم من ذلك.

1. ليس لدي الكثير (أو في الحقيقة أي خبرة) في إدارة الخوادم.
2. ربما سأحتاج إلى الوصول المادي إلى الآلات ، لأنها تبدو غير مستقرة تمامًا.

a7 عبارة عن جسر إلى i7 و v2 ، لذلك مع وجود a7 في الأسفل لا نعرف عن i7 و v2.

لا توجد مشكلة في الوصول ، يمكنني إعطائها لك. لكن يجب أن تدرك أن ترقية Jenkins هي عملية كبيرة لأنها تتطلب عادةً إعادة تكوين Jenkins (وفقًا لملاحظات الإصدار ، وهي كثيرة لأننا لم نقم بالترقية منذ فترة) وإصلاح Jenkinsfile (وفقًا لتغييرات واجهة برمجة التطبيقات من المكونات الإضافية ). مراسلتي على البريد الإلكتروني إذا كنت تريد الوصول.

a7 (وجميع الآخرين) مرة أخرى.

a7 معطلة مرة أخرى ، اتصلت بالمسؤول.

ملاحظة فنية: a7 نزل بسبب "القفل الناعم لعلة حراسة المراقبة".

يشير البحث السريع إلى أن هذه قد تكون مشكلة في BIOS. هل تحقق أي شخص من توفر تحديثات BIOS؟

a7 عبارة عن جسر إلى i7 و v2 ، لذلك مع وجود a7 في الأسفل لا نعرف عن i7 و v2.

هذا يبدو وكأنه تصميم سيء. ألا توجد طريقة للتغلب على ذلك؟

يشير البحث السريع إلى أن هذه قد تكون مشكلة في BIOS. هل تحقق أي شخص من توفر تحديثات BIOS؟

قمنا بتثبيت BIOS جديد ، واستبدلنا وحدة المعالجة المركزية وقمنا بترقية النواة (انظر الرسائل أعلاه). كان النظام مستقرًا منذ ذلك الحين. الآن بعد الترقية إلى Debian buster ، أصبح الأمر غير مستقر مرة أخرى.

ومع ذلك ، سألت المسؤول عما إذا كان يتوفر BIOS جديد.

هذا يبدو وكأنه تصميم سيء. ألا توجد طريقة للتغلب على ذلك؟

i7 و v2 موجودان في شبكة خاصة حيث لا توجد عناوين IPv4 كافية. سألت المسؤول لدينا عما إذا كان من الممكن إعداد IPv6.

سألت المسؤول لدينا عما إذا كان من الممكن إعداد IPv6.

لا نحتاج حقًا إلى IPv6 ، فسيكون ذلك كافيًا لاستخدام خادم آخر أكثر استقرارًا كجسر.

على الأرجح ، v2 غير مستقر مثل a7 (كان هناك عطل واحد فقط ولكن هذا لا يقول الكثير لأنه فورًا عندما يموت a7 ، فإنه يأخذ عبء v2). يمكننا استخدام i7 كجسر. ولكن إذا تعطل الإصداران 2 و a7 ، فإن i7 أيضًا ليس ذا فائدة كبيرة ، فقد يستغرق الأمر عدة ساعات لإنهاء مهمة البناء. علاوة على ذلك ، لا يحتوي i7 على مساحة كافية لتسجيل عامل الإرساء.

لذا فإن هذا التغيير يتطلب الكثير من الجهد مع القليل من المكاسب.

يعد إصلاح المشكلة الفعلية لـ a7 و v2 واعدًا أكثر.

علاوة على ذلك ، لا يحتوي i7 على مساحة كافية لتسجيل عامل الإرساء.

في هذه الحالة ، الحل الوحيد هو إصلاح a7.

لسوء الحظ سقط a7 مرة أخرى: البكاء:

حاولت التمهيد بالنواة القديمة ولكن هذا لم يساعد.

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

تمت ترقية BIOS لـ a7 حاليًا. علاوة على ذلك ، سنحاول استخدام نواة أحدث من backports.

ونأمل أن يكون a7 مرة أخرى قريبًا.

لم يساعد BIOS الجديد ، الآن تحطمت a7 في غضون دقائق.

a7 معطلة مرة أخرى ، اتصلت بالمسؤول. ستتم تجربة النواة الأحدث من backports في إعادة التشغيل التالية.

a7 مرة أخرى مع 5.2 kernel

أعتقد أنها تحطمت مرة أخرى ...

هل ما زلنا نتلقى نفس رسائل الخطأ أم أن هناك بعض التغيير على الأقل؟

نعم ، a7 أسفل مرة أخرى ، أبلغت المشرف. سيخبرنا عن الرسائل عند إعادة التشغيل.

هل لدى شخص ما فكرة أخرى؟ (لقد قمنا بترقية BIOS و Kernel بالفعل.)

تشير بعض المصادر إلى وجود مشكلات في برنامج تشغيل الرسومات nouveau وأنه يجب علينا تجربة nouveau.modeset=0 (بطريقة ما يختلف هذا عن nomodeset ). كما تم اقتراح تعطيل "حالات C" في BIOS.

نعم ، a7 أسفل مرة أخرى ، أبلغت المشرف. سيخبرنا عن الرسائل عند إعادة التشغيل.

هل لدى شخص ما فكرة أخرى؟ (لقد قمنا بترقية BIOS و Kernel بالفعل.)

ربما يتم تعطيل a7 كعبد جنكينز لتحديد ما إذا كان يحدث فقط عندما يكون التحميل "الحقيقي" على الجهاز.

ingwinlu شكرا لك ، فكرة جيدة. لقد اختزلت الآن إلى وظيفة بناء واحدة وهي a7 (كانت 2). في عطلة نهاية الأسبوع (بمجرد مغادرة المسؤول للمكتب) ، سأقوم بعد ذلك بتعطيل الوكيل تمامًا.

kodebach : شكرًا لك ،

هل هناك أي جدول زمني لموعد تشغيل a7 مرة أخرى؟

a7 يعمل مرة أخرى ، مع إيقاف تشغيل hyperthreading ووظيفة بناء واحدة فقط متزامنة.

يمكننا أيضًا إزالة بعض الأحمال من a7 ، عن طريق نقل alpine و ubuntu-xenial إلى Cirrus. كلاهما عبارة عن عمليات تشغيل بسيطة "للبناء والاختبار". إنهم لا يفعلون شيئًا خاصًا مثل تغطية التقارير.

يسمح Cirrus ببناء 8 Linux متزامنة لكل مستخدم . حاليًا ، يعد الإصدار linkchecker هو الإصدار الوحيد من Linux الذي تم إنشاؤه على Cirrus.

في الواقع ، ubuntu-xenial زائدة عن الحاجة بعض الشيء ، نظرًا لأن تصميمات Travis تعمل على Ubuntu Xenial.

شكرًا لك على النصائح ولكننا لا نخطط لإلغاء تحميل أي من إصدارات Linux بعيدًا عن Jenkins. على العكس من ذلك ، ستعمل Mistreated على تحسين البنية التحتية لـ Jenkins لتكون أكثر

1. نحن نمتلكها بالكامل تحت سيطرتنا
2. يمكننا توسيع نطاقه بسهولة (مطلوب فقط Java + Docker على وكلاء الإنشاء)
3. إن Jenkinsfile أنيق جدًا (بالنسبة لمعظم الأجزاء) قابل للتوسعة بسهولة تامة

ولكن بالطبع ، الجميع مرحب بهم أيضًا لتوسيع Cirrus (أو أي نظام بناء إضافي آخر يتم تقديمه مجانًا ، راجع # 1540).

كان من المفترض فقط أن يكون حلًا مؤقتًا ، لمواجهة تعطيل مؤشر الترابط المفرط والحد من وظيفة واحدة متزامنة على a7.

a7 يبني جزءًا صغيرًا فقط (حوالي 2/5) ، لذلك يجب أن يكون التخفيض بمقدار النصف بالكاد ملحوظًا. أم أن هناك مشاكل محددة الآن؟ (في الوقت الحالي ، بالطبع ، يستغرق الأمر بعض الوقت للحاق بالعديد من الوظائف منذ فترة التعطل.)

a7 يبني جزءًا صغيرًا فقط (حوالي 2/5)

2/5 40٪. لن أعتبر ذلك جزءًا صغيرًا.

أم أن هناك مشاكل محددة الآن؟

لا ، في الواقع يبدو أنها تعمل بشكل أفضل من ذي قبل.

عذرًا ، قصدت حوالي 2/6 (1/6 هي i7 ، 3/6 هي v2). ولا يتم إزالة هذا الجزء ولكن يتم تصغيره فقط.

لا ، في الواقع يبدو أنها تعمل بشكل أفضل من ذي قبل.

ممتاز!

يبدو أن a7 معطل

شكرا لك! لقد أبلغت عنها.

سيكون من الرائع في المستقبل أن يقوم الشخص الذي يكتشف أولاً بإبلاغ ذلك مباشرة

herbert في complang.tuwien.ac.at

يكفي أن نقول "a7 ist leider nicht erreichbar".

ثم أبلغ عن ذلك هنا أيضًا ، حتى لا يتلقى هربرت عدة رسائل بريد إلكتروني.

بالتأكيد هناك طريقة لجعل خادم Jenkins الرئيسي يرسل مثل هذا البريد الإلكتروني تلقائيًا وربما أيضًا النشر في مشكلة GitHub هذه. سيكون الأمر غريبًا جدًا ، إذا لم يكن هناك مكون إضافي لـ Jenkins لمثل هذه المهمة البسيطة ...

نعم ، هناك https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin لكنني لست متأكدًا من أنه يفعل ما نريده بالضبط. قد يرسل أيضًا رسائل بريد إلكتروني عندما يقوم شخص ما بإيقاف الوكيل عن قصد. ومن المرجح أن يتعامل المسؤول مع البريد الإلكتروني الشخصي بشكل أسرع.

إذا قمنا بأتمتة شيء ما ، فسيتم إعادة تشغيل أجهزة الكمبيوتر مباشرةً إذا كان يتعذر الوصول إليها (ربما يكون لديهم نوع من المراقبة المدمجة؟)

تم إعادة تشغيل a7 وتعطيل "التحكم العام في C-State".

ومع ذلك ، فهو ليس عبر الإنترنت كعامل بناء.

دعونا نرى ما إذا كان يتعطل أيضًا بدون تحميل. v2 و i7 يعملان مرة أخرى.

المشرف (هربرت) غير متاح غدًا ، لذلك أترك a7 وكيلًا للبناء في الوقت الحالي.

خطتي (إذا لم تكن هناك احتجاجات أو تعطل a7 من قبل) هي تشغيل a7 كعامل بناء غدًا. إذا تعطل a7 مرة أخرى ، يمكن لـ Herbert إعادة تشغيل a7 يوم الجمعة. هل هذا عادي او طبيعي؟

إذا لم تكن قائمة الانتظار طويلة جدًا ، أعتقد أننا يجب أن نبقي عامل الإنشاء على a7 معطلاً لفترة أطول قليلاً. وقع آخر حادث تحطم بعد 3 أيام. إذا قمنا بتمكينه غدًا ، فلن نعرف ما إذا كان وكيل الإنشاء قد تسبب في التعطل أم لا ، إلا إذا تعطل قبل ذلك.

حسنًا ، دعنا نرى كيف يبدو حجم قائمة الانتظار.

آمل أن تعمل "السيطرة العالمية للدولة الثالثة" على حل المشكلة أخيرًا وأعتقد أننا بحاجة إلى عبء كبير لاختبارها.

كانت قائمة الانتظار طويلة جدًا وكانت جميع الإنشاءات الرئيسية معلقة لأنها تحتاج إلى a7 لنشر موقع الويب.

لذلك بدأت عميل a7 مرة أخرى.

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

• استخدم jenkins build libelektra please في تعليق أسفل PR لإعادة تشغيل بناء Jenkins ، أو
• أعد كتابة آخر التزام بدون تغييرات (على سبيل المثال ، باستخدام git commit --amend ) وقم بدفع القوة

. نأسف للإزعاج.

شكرا لك على الحفاظ عليه!

لقد قمت بتمييز العقدة v2-debian-buster أنها غير متصلة مؤقتًا ، حيث يبدو أنها لا تعمل بشكل صحيح. لمزيد من المعلومات ، يرجى إلقاء نظرة على الإصدار رقم 2995 (والإصدار رقم 2994).

شكرا لبحثك عن البنية التحتية!

كان الإصدار 2 من مساحة القرص. قمت بتنفيذ docker system prune إجمالي المساحة المستصلحة: 58.37 جيجا بايت

ثم أعدت تشغيل الإصدار 2 وجعلت الوكيل يتصل مرة أخرى.

قمت الآن بتنفيذ du -h | sort -h للعثور على الملفات الأخرى المراد إزالتها.

لقد بدأت v2 مرة أخرى بإصدار Docker جديد. الرجاء الإبلاغ عن البنيات المعطلة على الفور.

أعدت تثبيت عامل الإرساء ، وتطهير جميع التكوينات ، وإزالة / var / lib / docker. نأمل أن هذا يصلحها.

سيتم تضمين الإصدار 2 مرة أخرى.يرجى الإبلاغ عن الإنشاءات المعطلة على الفور.

كما هو مقترح هنا قمت بتنفيذها الآن

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 (كان هناك العديد من واجهات شبكة عامل الإرساء ، لقد اختفت الآن)

الآن في كل مكان 5:19.03.1~3-0~debian-buster

الرجاء الإبلاغ عن البنيات المعطلة على الفور.

يبدو أن الإصدار master فشل مرة أخرى ، بسبب مشاكل الاتصال بـ v2-debian-buster (راجع أيضًا المشكلة رقم 2995).

طلبت من مسؤولنا النظر في التبديل بين a7 / v2 / i7. لقد ألغيت تنشيط v2 و i7 في الوقت الحالي.

أعدت تشغيل libelektra / master و libelektra-daily.

قمنا بتغيير المنافذ لجميع أجهزة الكمبيوتر الثلاثة.

ثم قمت بإزالة jenkins homedir على v2 / i7 وأعدت تشغيل وكيل v2 / i7.

يبدو أنه لم يعد

حالة خروج الطبقة 1 stdout: stderr: write /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o: لا توجد مساحة على الجهاز

.

شكرًا لك على الإبلاغ ، لقد وفرت مساحة أكبر (كثيرًا) في الإصدار 2.

انتهت إزالة الوظيفة:

حجم نظام الملفات المستخدم متوفر استخدم٪ Mounted on
/ dev / sda3 417G 227G 164G 58٪ /

buildserver معطل بسبب الترحيل (حتى نحصل على حالة متسقة في النسخة الاحتياطية لخادم البناء الجديد)

https://build.libelektra.org/jenkins/ يبدأ مرة أخرى

كان التحميل على خادم الإنشاء 200 بسبب أخطاء kernel أثناء النسخ الاحتياطي ، ولم يعد الخادم يتفاعل بعد الآن ويحتاج إلى إعادة تعيينه.

كانت رسائل السجل (أمثلة):

[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 ؟)

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

لم يعد يتم تنفيذ تصميمات Jenkins بعد الآن ، انظر # 3035

بدأ جينكينز الآن مرة أخرى. من فضلك كرر Jenkins بناء الوظائف.

يبدو أن v2-debian-buster غير متصل:

فتح اتصال SSH بـ a7.complang.tuwien.ac.at:22221.
تم رفض الاتصال (تم رفض الاتصال)

.

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

قام هربرت بالفعل بإعادة تشغيل الإصدار 2 أمس. قام بتعطيل "multithreading في وقت واحد".

إذا تعطل خادم (v2 ، i7 ، a7) مرة أخرى ، يرجى أيضًا الاتصال مباشرة بالمسؤول عبر "herbert at complang.tuwien.ac.at". يرجى أيضًا الإبلاغ هنا ، لتجنب رسائل البريد الإلكتروني المتعددة.

أعتقد أن هناك خطأ ما في مستودع Git للفرع 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

. لقد قمت بالفعل بإعادة تشغيل البناء ثلاث مرات ، لكن Jenkins يفشل دائمًا بنفس الخطأ.

لسوء الحظ ، يحتوي الإصدار 2 على 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

نظرًا لأنني لست متاحًا الآن لبضعة أيام ، يرجى الاتصال بـ "herbert at complang.tuwien.ac.at" بشأن المشكلات المتعلقة بتعذر الوصول إلى a7 / i7 / v2. سيكون Mistreated مسؤولاً عن كل ما لا يتعلق بإعادة تشغيل الخوادم. (نأمل أن نحصل على وكيل إنشاء جديد قريبًا.)

يرجى أيضًا الإبلاغ هنا دائمًا ، لتجنب رسائل البريد الإلكتروني المتعددة وحتى يكون لدى الجميع نظرة عامة جيدة على ما يجري.

هل يوجد عطل في خادم البناء حاليًا؟
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

هل يوجد عطل في خادم البناء حاليًا؟

يبدو أن خادم إنشاء Jenkins الرئيسي غير قادر على الاتصال بـ i7 . لقد قمت بتمييز العقدة على أنها غير متصلة بالإنترنت مؤقتًا.

فشل البناء في القضايا التعسفية:
هنا انقطعت دون أي سبب
هنا تفشل حالة اختبار لا علاقة لها بعلاقات عامة (لقد أضفت للتو قرار تصميم بدون لمس أي رمز)

هنا انقطعت دون أي سبب

حصلت على نفس رمز المقاطعة 143 لاثنين من العلاقات العامة ولا يمكنني شرحهما حتى الآن. أعدت تشغيل البناء وآمل أن يعمل الآن.

هنا فشلت حالة اختبار لا علاقة لها بعلاقاتي العامة

يجب إصلاح هذا بفضل sanssecours مع # 3103. الرجاء تغيير العنوان الأساسي للإتقان.

و العقدة جنكينز جديد hetzner-jenkins1 لا يبدو أن العمل بشكل صحيح . لقد قمت بتمييز العقدة على أنها غير متصلة بالإنترنت مؤقتًا.

لقد قمت بترقية docker على i7 وأعدت تشغيل الجهاز. آمل أن يحل هذا المشكلة. الوكيل متصل بالإنترنت مرة أخرى. الرجاء الإبلاغ عن المشاكل هنا (و / أو إلغاء تنشيط الوكيل).

حاليا وظيفة # 3065 تعمل على i7.

Mustreated هل يمكنك تصحيح أخطاء hetzner-jenkins1 من فضلك؟

هل هناك إمكانية لإيقاف تشغيل فحص الارتباط بسهولة لبعض الوقت؟

كان هذا يحدث طوال اليوم:

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). وفقًا لـ downforeveryoneorjustme ، فإن الروابط غير متوفرة بالفعل.

تحديث: الموقع لا يزال غير متصل. لقد صنعت العلاقات العامة لهذا # 3117.

هل هناك إمكانية لإيقاف تشغيل فحص الارتباط بسهولة لبعض الوقت؟

يمكنك إيقاف تشغيل الروابط الفردية عن طريق إضافتها إلى الاختبارات / linkchecker.whitelist (كما اكتشفت بالفعل)

لا يمكنني إعادة تشغيل البنيات الفاشلة من Cirrus. راجع https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

الزر لا يفعل شيئًا. هل هناك خدعة سحرية لجعلها تعمل؟

تحرير: إما أن يقوم شخص ما بتغيير شيء ما أو نجحت المحاولة x أخيرًا. البناء يعمل مرة أخرى! :)

يبدو أن وكيل الإنشاء 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 أخيرًا. البناء يعمل مرة أخرى! :)

بعد أن رأيت تعليقك قمت بالضغط على الزر "إعادة تشغيل وظائف البناء الفاشلة" أيضًا. بقدر ما أستطيع أن أقول إن الضغط على الزر بالفعل إعادة تشغيل وظائف البناء الفاشلة.

بعد أن رأيت تعليقك قمت بالضغط على الزر "إعادة تشغيل وظائف البناء الفاشلة" أيضًا. بقدر ما أستطيع أن أقول إن الضغط على الزر بالفعل إعادة تشغيل وظائف البناء الفاشلة.

لم ينجح الأمر بالنسبة لي رغم ذلك ، سأقدم بعض الصور المتحركة في المرة القادمة!

سأعيد تشغيل خادم البناء وعقده. يجب إعادة بناء وظائف # 3121 و # 3099 حيث كان لديهم وظائف على وكلاء ميتين.

لم ينجح الأمر بالنسبة لي رغم ذلك ، سأقدم بعض الصور المتحركة في المرة القادمة!

لست بحاجة إلى تقديم صورة GIF ، لأنني أعتقد ذلك بالفعل 😊.

يبدو أن Jenkins لديه مشاكل في التوقف ، أنتظر قليلاً قبل أن أقوم بقتل جميع عمليات Java بالقوة.

لقد قمت أيضًا بترقية عامل الإرساء على جميع الوكلاء (تمت ترقيته بالفعل على i7).

عاد Jenkins مرة أخرى بفاصل ضربات القلب كما هو مقترح في # 2984. جميع العقد متصلة.

يرجى إعادة تشغيل جميع الوظائف حسب الحاجة والإبلاغ عن أي مشاكل هنا.

v2 معطلة ، طلبت من المسؤول إعادة التشغيل.

لقد قمت بتمكين الإصدار 2 مرة أخرى ، حيث يبدو أنه قد تم رفعه وأن حجم تراكم البناء لدينا مناسب.

هل توجد مشكلة في الإنشاء مرة أخرى ( hetzner-jenkins1 )؟
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

"

هل توجد مشكلة في الإنشاء مرة أخرى ( hetzner-jenkins1 )؟

نعم . لقد عطلت العقدة.

لقد تجاوزت فقط حصة القرص ، لم أكن أريد أن أبالغ في الذاكرة. أنا نظفتها الآن. انها تصل مرة أخرى.

تم تحديث العقدة.

لقد قمت بزيادة hetzner-jenkins1 إلى 4 بنى متوازية. هذا مجرد إجراء مؤقت طالما أنه لا يوجد شيء آخر يعمل هناك.

لقد خفضت مؤقتًا عدد المنفذين في hetzner-jenkins1 من 4 إلى 2 ، حيث تنتهي مهلة الاختبار. أعتقد أن هذا يحدث عندما يتم تجميع عدد كبير جدًا من الوظائف أثناء إجراء الاختبارات. قد نحتاج إلى تقييد الموارد المتاحة لحاوية واحدة لا تتداخل كثيرًا مع الوظائف الأخرى.

لا تتردد في تصحيحها إذا كنت تعتقد أن هذا كان النهج الخاطئ.

EDIT: تم تقليله إلى 1 نظرًا لأن الاختبارات لا تزال تنتهي وإعادة بناء المزيد من النفايات باستمرار.

mpranj شكرا لك على

mistreated هل ربما قمت فقط بتعيين وحدة معالجة مركزية واحدة أو ما شابه ذلك؟ هل يمكنك تعيين المزيد وزيادة عدد المنفذين؟ يجب أن يكون الجهاز أقوى مثل v2.

لقد عطّلت i7-debian-buster لعدم وجود مساحة على القرص مما يؤدي إلى فشل كافة الإصدارات. إذا كان لدى شخص ما حق الوصول ، فيرجى تنظيف شيء ما وإعادة تمكينه.

mpranj شكرا لتعطيل!

عذرًا ، حيث أنا حاليًا محظور ssh (لا يعمل جدار حماية بعض التطبيقات ، وكذلك ssh على المنافذ الأخرى). لذلك لا يمكنني منح حق الوصول أو القيام بأي تنظيف الآن.

نظرًا لأن i7 هو أضعف الوكلاء ، فقد لا يمثل مشكلة كبيرة على أي حال.

Mistreated هل ربما قمت فقط بتعيين وحدة معالجة مركزية واحدة أو ما شابه ذلك؟ هل يمكنك تعيين المزيد وزيادة عدد المنفذين؟ يجب أن يكون الجهاز أقوى مثل v2.

ليس لدي أي فكرة عن مدى قوة الإصدار 2.
حاليًا يستخدم jenkins1 4 وحدة معالجة مركزية بذاكرة 8 و 16 مقايضة. يمكنني زيادتها بسهولة ، فأنا لا أعرف إلى أي نقطة تريد مني زيادتها.

ملاحظة لقرارات الأجهزة المستقبلية: يبدو أن phoronix يقوم باختبارات تجميع في مقالات وحدة المعالجة المركزية الخاصة بهم (مثل Ryzen 7 3700X ، اختبار Ryzen 9 3900X ، في نهاية المقالة ).

يبدو أن hetzner أضاف مؤخرًا AMD Ryzen 7 3700X إلى خوادمهم القائمة على AMD.

ليس لدي أي فكرة عن مدى قوة الإصدار 2.

كتب ingwinlu عن هذا في أطروحته (يمكن العثور عليها في abgaben repo lukas_winkler)

يستخدم jenkins1 حاليًا 4 وحدة معالجة مركزية مع ذاكرة 8 و 16 مقايضة. يمكنني زيادتها بسهولة ، فأنا لا أعرف إلى أي نقطة تريد مني زيادتها.

طالما لم يكن لدينا أي شيء آخر يعمل على الخادم ، يمكنك تخصيص جميع الموارد. في وقت لاحق لا يزال بإمكاننا النزول (عندما ننقل جنكينز).

لقد قمت بتحديث ملف hetzner-jenkins1.
تم تصحيح الخطأ في الواجهة الأمامية عند نفاد الذاكرة.
الآن يتم تشغيل بنائين متوازيين.

يبدو أنه لا توجد مساحة متبقية على v2-debian-buster :

validation.cpp:69:1: fatal error: error writing to /tmp/cccJFleY.s: No space left on device

.

شكرًا لك ، لقد قمت بتمييزه في وضع عدم الاتصال أيضًا ، حتى يتمكن شخص ما من الوصول إليه لتنظيفه.

hetzner-jenkins1 أخفق للتو في 3 PRs الخاصة بي بسبب تجاوز حصة القرص. هنا على الإخراج:

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
• الإصدار 2: / dev / sda3 417G 255G 147G 64٪ /

ثم أعدت تشغيل الوكلاء.

Mistreated هل يمكنك من فضلك إصلاح # 3160 حتى لا يتكرر ذلك بسرعة. يرجى أيضًا إصلاح hetzner-jenkins1. هناك الكثير من الموارد على هذا الجهاز ، ليس من الضروري حقًا أن يصل إلى حد الموارد كل يوم.

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

لم يعد الإصدار 2 من المساحة مرة أخرى ، قمت بالتنظيف: / dev / sda3 417G 315G 102G 76٪ /

Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log لا يبدأ

أعتقد أن نظام البناء عالق تمامًا حاليًا ، ولا يتم بناء العلاقات العامة.

شكرًا لك على الإبلاغ ، سأقوم بإعادة تشغيل Jenkins وتنظيف بعض الملفات لأن القرص ممتلئ.

Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log لا يبدأ

الوكيل متصل ومتصل بنجاح

أفترض أن كل شيء على ما يرام الآن مع Htnzer-jenkins1؟

شكرا جزيلا! يبدو أن Jenkins لا يزال لا يتفاعل مع البنايات. V2 و i7 الآن على حد سواء فشل مع: java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave .

عاد جينكينز مرة أخرى ، يرجى إعادة تشغيل الوظائف.

java.io.IOException: تعذر نسخ slave.jar إلى "/ home / jenkins" على التابع.

تم إصلاحه (كان أيضًا خارج المساحة)

Mistreated ، يرجى إصلاح

Mistreated "

ربما حاول اليوم التغيير إلى Jenkins الجديد ولكن إذا لم تكن قادرًا على القيام بذلك ، فالرجاء جعل النسخة القديمة تعمل مرة أخرى!

لقد أطلقت فحصًا للمستودع ، والآن يبدو أن "jenkins build libelektra من فضلك" يعمل مرة أخرى.

يبدو أن القرص ممتلئ مقابل v2-debian-buster

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

لسوء الحظ. لقد حددت v2 أنه غير متصل حتى يتم حلها.

شكرا على الإبلاغ!

mpranj لقد

شكرا لك! يبدو لي أن هناك وفرة من الموارد التي أهدرت بسبب الصور القديمة لرسو السفن الكاذبة. بالإضافة إلى ذلك ، يبدو أن btrfs + docker هي عربات التي تجرها الدواب. يقوم Docker بإنشاء وحدات تخزين فرعية btrfs لكل حاوية ولا يقوم بتنظيفها بعد ذلك. الأمر docker system prune -f لا يفرغ المساحة أيضًا.

لقد قمت بتخفيض v2 و a7 للصيانة لتحرير الموارد وتحقيق التوازن في btrfs.

فشل تسجيل دخول عامل ميناء

بناء غير قادر على سحب صور عامل ميناء. شيء ما يحدث مع Docker hub؟

نعم ، آسف ، مع a7 قمت أيضًا بإزالة لوحة Docker. سوف أنشر رسالة هنا عندما يعود الأمر مرة أخرى.

عاد a7 بما في ذلك محور عامل الإرساء مرة أخرى. تركت v2 عدم الاتصال لأنه لا يمكنه تسجيل الدخول إلى لوحة الوصل لسحب الصور؟!؟ لا أعرف ما هو الخطأ هناك ، لم أغير أي بيانات اعتماد أو نحو ذلك ويمكن للعقد الأخرى تسجيل الدخول. أيه أفكار؟

لا يزال Btrfs يتوازن في الخلفية ، وقد يكون a7 أبطأ لمدة ساعة أخرى أو نحو ذلك.

mpranj شكرا لك على إصلاح هذا! ما هي الأوامر اللازمة لإعادة موازنة btrfs؟

لسوء الحظ ، لا أعرف أوراق الاعتماد ، آمل أن تتمكن ingwinlu من مساعدتنا.

كانت الأوامر التي استخدمتها لإعادة التوازن هي:

إصلاح خطأ ربما مع btrfs:

btrfs balance start -dusage=0 -musage=0 /mountpoint

أعد توازن fs حقًا ، فهذا يستغرق وقتًا طويلاً. يمكن / يجب ضبط معلمة الاستخدام ، وهذا ما نجح اليوم:

btrfs balance start -dusage=80 /

يمكن تغيير بيانات الاعتماد بسهولة ، ولكن سيتعين علينا تسجيل الدخول إلى جميع وكلاء jenkins الذين يتصلون بلوحة Docker مرة أخرى باستخدام بيانات الاعتماد الجديدة.

كانت المشكلة الأكبر هي أن بعض حاويات الرصيف كانت لا تزال تعمل وأن نظام تقليم الرصيف لم يفعل الكثير. لذلك قمت بإنزال العملاء وحررت كل شيء أثناء تعطله. كان هناك أطنان من الحاويات ملقاة في الجوار.

نعم ، للأسف يتم إعادة إنشاء الحاويات بسرعة. آمل أن يتمكن Mistreated من إصلاح الوظيفة اليومية libelektra قريبًا (يتم تنفيذ docker system prune ).

لقد قمت أيضًا ببعض التحاليل الجنائية الرقمية ذات الصلة وسرقت بيانات اعتماد المركز. : يضحك:

v2 مرة أخرى.

شكرا جزيلا! : 100: من فضلك أرسل لنا أوراق الاعتماد.

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

فكرة أخرى: ربما يمكننا القيام بوظائف التنظيف الحرجة بالإضافة إلى ذلك لكل cronjob لتجنب مواقف مثل التي كانت لدينا الآن.

من فضلك أرسل لنا أوراق الاعتماد.

mpranj أعتقد أنني كنت في هذه المجموعة من "نحن". لم أكن في بعض CC أو شيء من هذا القبيل؟

Mistreated آسف ، لقد أرسلته إلى ماركوس ولم يكن لدي بريدك الإلكتروني. على a7 ستجد CREDENTIALS.txt في homedir الخاص بك.

أحتاج عقدة hetzner-jenkins1 لاختبار خادم jenkins الجديد. سأقوم بإيقاف تشغيله على الخادم القديم حتى صباح الغد.

يمكنك بسهولة إنشاء hetzner-jenkins2 آخر للاختبارات. إذا كانت هذه الليلة فقط ، فلا بأس بذلك.

فكرة أخرى: ربما يمكننا القيام بوظائف التنظيف الحرجة بالإضافة إلى ذلك لكل cronjob لتجنب مواقف مثل التي كانت لدينا الآن.

يقوم libelektra-daily بمهام التنظيف هذه ولكنه فشل الآن: # 3160. إذا كانت لديك أفكار لتحسين هذه الوظيفة ، فيرجى إخبارنا.

أعتقد أنني كنت ضمن هذه المجموعة "نحن". لم أكن في بعض CC أو شيء من هذا القبيل؟

نعم ، آسف لقد نسيت أن أقول لـ mpranj أن "نحن" تشير إليك.

آمل أن يكون من الجيد الاحتفاظ بـ hetzner-jenkins1 لبعض الوقت ، كل البنيات جيدة الآن أعتقد أنه يمكنني جعل الخادم يعمل بشكل كامل الليلة.

v2 لا يمكن الوصول إليه ، لقد اتصلت بالمسؤول.

آمل أن يكون من الجيد أن أحتفظ بـ hetzner-jenkins1 لبعض الوقت ، كل الإنشاءات جيدة الآن أعتقد أنه يمكنني جعل الخادم يعمل بشكل كامل الليلة.

هذا سيكون أمرا رائعا!

v2 لا يمكن الوصول إليه ، لقد اتصلت بالمسؤول.

شكرا لك ولكني أخشى ألا يرد قبل يوم الاثنين.

يحصل الإصدار 2 على نواة جديدة (تحطمت للتو).

سيتم أيضًا إعادة تشغيل i7.

جميع الخوادم الثلاثة (v2، a7، i7) لديها الآن "Linux v2 5.2.0-0.bpo.2-amd64 # 1 SMP Debian 5.2.9-2 ~ bpo10 + 1 (2019-08-25) x86_64 GNU / Linux "

إنهم متصلون ومتصلون ، يرجى إعادة تشغيل الوظائف إذا لزم الأمر.

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

يبدو أن Master [1] تم بناؤه أيضًا على الخادم الجديد. لم يكن بنجاح. عند النقر فوق الحالة ، تظهر صفحة تسجيل الدخول [2]. يرجى إعادة تكوين Jenkins بحيث يمكن عرض كل شيء دون تسجيل الدخول.

نأمل أن نتمكن من التبديل إلى Jenkins الجديدة قريبًا. رؤية الأخطاء من اثنين من Jenkins مختلفة لا تجعل الموقف أسهل: غمزة:

[1] https://github.com/ElektraInitiative/libelektra/commits/master#
[2] http://95.217.75.163 : 8080 / تسجيل الدخول؟ من =٪ 2Fjob٪ 2Flibelektra٪ 2Fjob٪ 2Fmaster٪ 2F1٪ 2Fdisplay٪ 2Fredirect

@ markus2330 هل يمكن إعادة تشغيل a7 / v2 عن بُعد بعد الترقية أم أن هناك بعض المزالق؟

عادة ما يعمل ولكن إذا لم يكن الأمر عاجلاً فمن الأفضل الانتظار حتى يكون هناك المسؤول. يمكنني إعادة التشغيل يوم الثلاثاء إذا كان هذا على ما يرام بالنسبة لك؟

شكرا لك! لا شيء عاجل ، مجرد سؤال عام. جاء لأنه تم إطلاق Debian 10.2 للتو. سأنتظر قليلا مع الترقيات.

يمكنك القيام بالترقية مع ذلك (فقط بدون إعادة تشغيل). بعد ذلك ، في حالة حدوث عطل ، سيكون لدينا بالفعل نواة 10.2 عندما يضغط المسؤول على زر إعادة الضبط: wink:

mpranj هل يمكنك إضافة cronjob الذي يطهر اللقطات القديمة؟ أم أن هذا غير ممكن بدون توقف عامل الميناء؟

https://docs.docker.com/storage/storagedriver/btrfs-driver/ يوصي أيضًا بإعادة توازن btrnfs في cronjob.

هل يمكنك إضافة cronjob الذي يطهر اللقطات القديمة؟ أم أن هذا غير ممكن بدون توقف عامل الميناء؟

يمكنني إضافة cronjob دون إيقاف جميع حاويات عامل التحميل. قد لا يؤدي هذا إلى تنظيف كل شيء ، ولكن يمكننا تجربته. كما قلت ، في بعض الأحيان تستمر الحاويات في العمل إلى الأبد / حتى تعطل الجهاز. يتطلب التنظيف الكامل منا تعطيل عامل الإنشاء مؤقتًا ، ومع ذلك يمكننا إيقاف جميع الحاويات بالقوة.

يمكنني أيضًا إضافة إعادة التوازن كـ cronjob.

شكرا لك ، دعونا نجربها.

المعلم نفد من الذاكرة. أردت تشغيل Scan Repository على Jenkins القديمة لأن a7 و i7 يحصلان على الخطأ التالي عند سحب صور عامل الإرساء:

فشل تسجيل دخول عامل ميناء

حصلت على v2 و hetzner-jenkins1 قيد التشغيل على الخادم الجديد الآن.

المعلم نفد من الذاكرة.

شكرا على الإبلاغ. أزلت بعض بيانات التغطية القديمة وقمت بتمكين العقدة الرئيسية مرة أخرى. لكل شخص لديه طلبات سحب مفتوحة: يرجى إعادة تشغيل تصميمات Jenkins jenkins build libelektra please . نأسف للإزعاج.

في # 3234 ، اقترح @ raphi011 :

imo هذا أمر ملح حقًا ، فالتقلب والبطء في الاختبارات يجعل من الصعب إن لم يكن من المستحيل إجراء أي تغييرات إذا كان عليك الانتظار كل هذا الوقت للتحقق منها.

أوافق على أنه أمر عاجل حقًا ولكن Mistreated يفعل بالفعل ما في

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

أو ماذا عن (مؤقتًا) إيقاف البناء التلقائي للعلاقات العامة عند دفع التغييرات (بحيث يبدأ البناء فقط بـ jenkins build libelektra please )؟ Mistreated هل تعرف كيفية إعادة تكوين Jenkins للقيام بذلك (لم أجد الخيار)؟

لدي أيضًا شعور بأن jenkins build libelektra please لا يعمل في الوقت الحالي ، على الأقل لم ينجح في هذا الإصدار: https://github.com/ElektraInitiative/libelektra/pull/3073 اضطررت إلى دفع التزام فارغ لبدء خط الأنابيب.

تم تنفيذ Cleanup cronjob وترقية backport kernel على a7 و v2. هناك تغيير كبير في kernel ، سيكون نشطًا عند إعادة التشغيل التالي.

شكرا جزيلا! هل ما زالت نواة backport "القديمة" مثبتة بحيث يكون لدينا احتياطي إذا لم يتم التمهيد؟

نعم ، يمكن إزالته بعد التمهيد الناجح في النواة الجديدة.

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 للتنظيف اليدوي وترقية kernel و docker. قام شخص ما بتمكين i7 أثناء عملي عليه. كل شيء يعمل مرة أخرى.

Piankero لقد

لدي أيضًا شعور بأن jenkins build libelektra please لا يعمل في الوقت الحالي ، على الأقل لم ينجح في هذا الإصدار: # 3073 كان علي دفع التزام فارغ لبدء خط الأنابيب.

يعمل الان

Mistreated هل تعرف كيفية إعادة تكوين Jenkins للقيام بذلك (لم أجد الخيار)؟

لقد أضفت ما يلي إلى تكوين Jenkins:

قم بإيقاف تشغيل SCM التلقائي

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

Mustreated شكرا لك! دعونا نرى ما إذا كان هذا كافيا. آمل أن تدفع لإتقان ما زالت تؤدي إلى بناء سيد؟

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

Mustreated شكرا لك! دعونا نرى ما إذا كان هذا كافيا. آمل أن تدفع لإتقان ما زالت تؤدي إلى بناء سيد؟

الفرع الرئيسي هو الآن استثناء من القاعدة التالية:

قم بإيقاف تشغيل SCM التلقائي

أما بالنسبة لل

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

أضفت CT جديد (hetzner-jenkinsNode3).

تعذر استنساخ الريبو: https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

ربما هذا له علاقة بالعقدة الجديدة؟ (تخمين جامح)

ربما هذا له علاقة بالعقدة الجديدة؟ (تخمين جامح)

هذا الخطأ موجود على a7

هذا الخطأ موجود على a7

سووو .. أعد المحاولة؟

سووو .. أعد المحاولة؟

نعم ، لا أعتقد أن ذلك سيحدث مرة أخرى ..

سأعيد تشغيله من أجلك.

Mistreated أعتقد أنه يمكننا بدء عمليات

أي فكرة لماذا هذا سيفشل؟

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

أي فكرة لماذا هذا سيفشل؟

يبدو أنها كانت مشكلة مؤقتة ، يمكن الوصول إلى عنوان URL حاليًا من وكلاء الإنشاء.

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

حسنًا .. jenkins build libelektra please الثالث

نعم ، لدينا جميع التبعيات مباشرة في صور عامل الميناء لهذا السبب بالضبط. لقد خلقت # 3251

أخذت v2 و a7 في وضع عدم الاتصال لإعادة التشغيل.

@ markus2330 إذا فقم بتمكين الترابط التشعبي على a7 .

تم تشغيل v2 مرة أخرى ، في a7 لا يزال هناك buildjob.

أخذت العقد وأضفتها إلى الخادم الجديد. سأتركه يركض طوال الليل. Tomorow سأعيد العقد إذا كانت هناك أخطاء أخرى على خادم Jenkins الجديد.

سيستمر تشغيل hetzner-jenkinsNode3 على Jenkins القديمة.

Tomorow سأعيد العقد إذا كانت هناك أخطاء أخرى على خادم Jenkins الجديد.

أخطاء البناء الصغيرة ليست سببًا للعودة. في مرحلة ما ، نحتاج إلى إصلاح الأخطاء ، حيث تستغرق عملية الانتقال ذهابًا وإيابًا وقتًا طويلاً.

ومع ذلك ، فإن ما قد يكون أداة إيقاف العرض هو أن الخادم الجديد لا يمكن الوصول إليه. (لا
http://95.217.75.163:8066 ولا ssh). لقد ضغطت على زر الطاقة ، دعنا نرى ما إذا كان الجهاز سيُعاد تشغيله. يجب أن نحقق في سبب المشكلة.

http://95.217.75.163 : 8066

إذا كان هناك وقت ، فالرجاء تمكين TLS باستخدام Letsencrypt ، حتى لا نسرب بيانات الاعتماد ونعرض أنفسنا لمشكلات أخرى مختلفة؟

شكرا لك على المدخلات! أود أن أقترح القيام بذلك على الفور عندما نبدل build.libelektra.org. وإلا فلدينا جهود مضاعفة.

هل هذا الخطأ معروف؟ Caught the following exception: null

يبدو أن اختبار التنسيق فشل وتم إنهاء البنيات الأخرى.

أنت على حق. يا لها من رسالة خطأ سيئة على الرغم من: P

Mistreated هل يمكنك من فضلك تنشيط أن العلاقات العامة يتم بناؤها تلقائيًا؟ نظرًا لوجود العديد من الوكلاء ، فإن الخادم ينام الآن معظم الوقت.

Mistreated هل يمكنك من فضلك تنشيط أن العلاقات العامة يتم بناؤها تلقائيًا؟ نظرًا لوجود العديد من الوكلاء ، فإن الخادم ينام الآن معظم الوقت.

منتهي.

سأقوم باستعارة hetzner-jenkins1 و v2 مرة أخرى للخادم الجديد.

لا تحتاج إلى إعادتها ، آمل أن نتمكن من إجراء التبديل اليوم.

نصيحة: عند إجراء هذا النوع من المحولات ، من الجيد تقليل مدة البقاء لمدخل DNS إلى شيء منخفض بشكل غير عادي (على سبيل المثال 60 بدلاً من 21599 حاليًا لـ build.libelektra.org). بعد نشر التغيير ، يجب أن يسمح لنا بتبديل إدخال DNS في غضون دقيقة بدلاً من ساعات. إذا فات الأوان ، فقد يساعد ذلك في مسح ذاكرة التخزين المؤقت لنظام أسماء النطاقات لـ google و opendns ، لكن بعض الأشخاص سيرون حتمًا المورد القديم حتى تنتهي صلاحية الإدخالات المخزنة مؤقتًا على مستوى العالم.

تحرير: بعد التغيير ، من الواضح أنه يجب إعادة TTL إلى بعض القيمة المعقولة لوضع عبء أقل على DNS.

على الرغم من أن الوقت قد فات الآن ، فقد بدلت $TTL 3600 (إذا احتجنا إلى عدة تغييرات حتى يعمل كل شيء).

يوجد بالفعل www-new and build-new للإشارة إلى الخادم الجديد.

لقد بدلت الآن doc.libelektra.org. Mistreated سيصلح النشر. سأبحث في www-new.libelektra.org

يجب أن يعمل https://build-new.libelektra.org/ و https://www-new.libelektra.org/home الآن.

سأغير جميع إدخالات DNS الآن.

تم تغيير كافة إدخالات DNS.

لسوء الحظ ، يفشل certbot حيث يبدو أنه يتحدث مع الخادم القديم ولكن يبدو أن هذا يؤثر فقط على التنزيل والمجتمع (عناوين URL الأقل استخدامًا).

لذلك نأمل ، خلال / بعد عطلة نهاية الأسبوع ، أن يرى الجميع أسماء DNS المحدثة.

Mistreated يرجى تحديث نشر جميع القطع الأثرية: أيضًا للموقع الإلكتروني. يرجى إنشاء علاقات عامة للتأكد من أن كل شيء يعمل بشكل صحيح.

تم الآن إيقاف تشغيل خادم الإنشاء القديم.

أحتاج إلى إعادة تشغيل الخادم الجديد (تمت إضافة نواة جديدة وجسر الشبكة).

الخادم يعمل مرة أخرى مع Linux pve 5.0.21-5-pve.

لقد حددت موعدًا لإعادة فحص جميع العلاقات العامة.

الخادم في وضع عدم الاتصال بسبب سوء التكوين / الخطأ في pve (تم حذف / etc / network / interfaces بواسطة واجهة المستخدم الرسومية؟).

كان الخطأ هو أن إعادة تسمية أجهزة الشبكة (التي نتجت عن عملي في واجهة المستخدم الرسومية) تؤدي إلى kernel OOPS:

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)

Mistreated master أيضًا لا يبدو أنه يبني تلقائيًا بعد الآن ، فأنا أقوم

أقوم بجمع أخطاء عاجلة في # 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

شكرا على الإبلاغ!

Mistreated هل يمكنك من فضلك تثبيت Naginator + Plugin # 2967 كما تمت مناقشته عدة مرات؟ (يرجى عمل لقطة قبل التغييرات على Jenkins.)

hetzner-jenkins1 : تم تجاوز حصة القرص

Mistreated هل يمكنك من فضلك تثبيت Naginator + Plugin # 2967 كما تمت مناقشته عدة مرات؟ (يرجى عمل لقطة قبل التغييرات على Jenkins.)

سأفعل ذلك اليوم

hetzner-jenkins1: تم تجاوز حصة القرص

mpranj لقد أضفت VM كعامل بناء بينما hetzner-jenkins1 معطل .

قمت بتنظيف بعض المساحة على hetzner-jenkins1 من خلال تشغيل docker system prune -a وتمكينه مرة أخرى.

يبدو أن هناك مشكلة مرة أخرى تتمثل في عدم تنظيف الكثير من الأشياء بواسطة docker system prune -f . هذه المرة لم يكن برنامج تشغيل التخزين btrfs ولكن vfs . :مشوش:

لقد أضفت جهاز VM الجديد كعامل بناء بينما تعطل hetzner-jenkins1.

الفكرة الآن هي أننا لا نستخدم الحاوية بعد الآن ولكن فقط VM بدلاً من ذلك.

قمت بتنظيف بعض المساحة على hetzner-jenkins1 عن طريق تشغيل docker system prune -a وقمت بتمكينه مرة أخرى.

شكرا جزيلا! يمكنك أيضا عمل cronjob هناك؟ (على الجهاز الظاهري ، وليس على الحاوية).

جعل cronjob هناك؟

منتهي.

Mistreated هل يمكنك من فضلك تثبيت Naginator + Plugin # 2967 كما تمت مناقشته عدة مرات؟ (يرجى عمل لقطة قبل التغييرات على Jenkins.)

يجب أن ننتقل من وظيفة خط الأنابيب إلى وظيفة حرة ، إذا أردنا إضافة naginator. سأبحث عن بدائل.

يبني على VM jenkinsNode3VM تفشل حاليًا. إنهم غير قادرين على سحب الرصيف:

unexpected EOF
script returned exit code 1

لقد قمت بتعطيله في الوقت الحالي حتى يتمكن شخص ما من حل المشكلة.

[cronjob] انتهى.

شكرا لك!

يجب أن ننتقل من وظيفة خط الأنابيب إلى وظيفة حرة ، إذا أردنا إضافة naginator. سأبحث عن بدائل.

نعم ، فكرة جيدة. ربما يكون من الأفضل ترميز ذلك في ملف Jenkins الخاص بنا. لذلك إذا فشلت مهمة / مرحلة إنشاء مشكلة ، تتم إعادة المحاولة. يتم تجربة عمليات سحب عامل الإرساء هذه مرتين على الأقل لأن هذه واحدة من أكثر المشكلات شيوعًا.

يبني على VM jenkinsNode3VM تفشل حاليا. إنهم غير قادرين على سحب الرصيف:

Mistreated الرجاء إصلاح هذا.

يبني على VM jenkinsNode3VM تفشل حاليا. إنهم غير قادرين على سحب الرصيف

لقد أصلحت صورة عامل الإرساء التي لا يمكن سحبها.

شكرا جزيلا! من المفيد دائمًا كتابة الخطأ وكيفية إصلاحه.

ليس لدي أي فكرة عن الخطأ ، لقد قمت ببناء الصورة يدويًا على الوكيل. منذ الوكيل لا يمكن أن يسحبه.

بالنسبة إلى Dockerfile (scripts/docker/debian/stretch) فإنني Visual Code يقول أنه يحتوي على سطرين emtpy في النهاية ، لكن vim يقول واحدًا فقط. لا أعلم أنه يجب أن تفعل شيئًا بالخطأ أعلاه ، ربما هو فقط VS .

يبدو أننا نواجه مشاكل مع سجل عامل الإرساء (فشل سحب عامل الإرساء رقم 3316 مع unexpected EOF ).

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

سأنتظر التعليق ما إذا كان هناك أي شيء ضد ذلك قبل أن أبدأ.

أعتقد أنها مشكلة في

(سكربت / عامل ميناء / ديبيان / امتداد)

الصورة ، لأنها الوحيدة التي تفشل.

لقد قمت ببنائه يدويًا مرة أخرى ، ولكن هناك بالتأكيد خطأ ما في الصورة الموجودة في التسجيل.

تقرير Jenkins: JenkinsNode3VM (غير متصل)

Mistreated سيكون رائعًا إذا كان بإمكانك إعداد طريقة ما للمراقبة.

a7 (وبالتالي v2 و i7 ) معطل. لقد اتصلت بالمسؤول.

تحرير markus2330: مرة أخرى

بسبب انقطاع التيار الكهربائي المخطط له في 08.07.2020 في TU Wien ، يخطط المسؤول لدينا لإغلاق جميع خوادم الإنشاء في اليوم السابق (الثلاثاء 7.7). ستكون عمليات الإنشاء بطيئة جدًا خلال ذلك الوقت ، لذا يرجى الضغط على ذلك اليوم فقط في الحالات العاجلة.

الخوادم متصلة بالإنترنت مرة أخرى باستثناء i7. لقد أبلغت المشرف.

كان هناك انقطاع آخر للتيار الكهربائي (غير مخطط له) أمس في المساء ، وبالتالي فإن جميع خوادم البناء معطلة الآن. المشرف يعمل على ذلك.

EDIT بعد 30 دقيقة: كل شيء ، بما في ذلك i7 ، عاد مرة أخرى: صاروخ:

@ markus2330 يبدو أن

لا أعلم عن أي تغيير ، فقط عن تشغيل أجهزة الكمبيوتر مرة أخرى بعد انقطاع التيار الكهربائي هذين (أحدهما مخطط والآخر غير مخطط له).

لكنك على حق ، أرى أيضًا أن هذين الاثنين (لكن ليس a7) ليس لديهما اتصال بالإنترنت بعد الآن ، على الرغم من أنه يمكن الوصول إليهما. سألت مشرفنا عن ذلك.

ربما نفصلهم عن Jenkins حتى يتم إصلاح هذه المشكلة؟

شكرا على اتصالك بالمسؤول! لقد قمت بفصل كل من i7 و v2 حتى يمكن حل المشكلة. (لا تعمل البنايات على أي حال لأنها لا تستطيع سحب صور عامل الإرساء)

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

دعونا نبقيهم منفصلين في الوقت الحالي.

تم حل مشكلة الإنترنت الآن وقمت أيضًا بتثبيت تحديثات الأمان على هذه الأجهزة.

mpranj هل يمكنك من فضلك تشغيلها مرة أخرى؟

شكرا لك @ markus2330.

عادت جميع العقد للاتصال بالإنترنت مرة أخرى.

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

تحركت

• [] جعل إرسال رسائل البريد الإلكتروني إذا فشل البناء أكثر موثوقية
• [] صورة Docker بدون مستخدم Jenkins
• [] صور سنتوس / فيدورا / عامل ميناء القوس
• [] حزم centOS
• [] وكلاء بناء freebsd / openbsd / solaris

إلى 3519 # و # 3519 أعلاه.

يمتلكrobaerd الآن أيضًا إمكانية الوصول إلى a7 / v2 / i7 ويمكنه الاتصال بالمسؤول في حالة حدوث مشكلات.

مجرد تقرير سريع عن أوقات الإنشاء (خط الأنابيب الرئيسي libelektra ):

• مع تمكين a7 : 2h 29m 24s
• مع تعطيل a7 : 1h 35m 45s

لماذا يظهر Jenkins أنه قد تم إغلاقه؟ سيكون من الجيد أن تقرأ هنا دائمًا مقدمًا: غمزة:

سيتم إغلاق Jenkins ، بسبب النسخ الاحتياطي الكامل للنظام وإعادة تنسيق أنظمة الملفات من btrfs إلى ext4.

جينكينز عاد مرة أخرى

سيكون Jenkins CI غير متصل للصيانة من حوالي الساعة 11:15 بتوقيت وسط أوروبا اليوم.

سنقوم ببعض مهام النسخ الاحتياطي والتنظيف ونحاول تحسين أداء a7 .

سيتم إخطارك مرة أخرى عند انتهاء الصيانة.

تم تشغيل Jenkins CI وجميع خوادم الإنشاء مرة أخرى. a7 المفترض أن يكون أداء

يرجى الإبلاغ إذا واجهت أي أخطاء.

سيكون Jenkins CI ووكلاء الإنشاء غير متصلين بالإنترنت لإجراء صيانة / تحديثات قصيرة.

تحرير: التحديثات تتم.

الخادم معطل ، أنا تحقق.

الخادم يعمل مرة أخرى.

بيان رسمي حول السبب: "كانت هناك مشكلة في PSU في الخادم المجاور والتي تسببت في إيقاف تشغيل الخادم ؛ وقد تم تصحيحها الآن."

ssd في a7 ممتلئ ، مما تسبب في فشل كل البنيات عليه.

سأحاول تحرير بعض المساحة. هل من الآمن فصل وكيل الإنشاء a7 من Jenkins في الوقت الحالي؟

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

سأحاول تحرير بعض المساحة. هل من الآمن فصل وكيل بناء a7 عن جينكينز في الوقت الحالي؟

بالطبع. على العكس من ذلك ، سيكون من غير الآمن إبقائها متصلة إذا تسببت في فشل جميع الإنشاءات.

أدى تشغيل docker system prune -a تنظيف ما يقرب من 50٪ من المساحة مرة أخرى. ربما نحتاج إلى تكييف cronjob الحالي لإضافة علامة -a ؟

يستخدم منزل جنكينز مساحة كبيرة أيضًا.

البناء الرئيسي (خط الأنابيب الكامل مع حزم deb وبناء موقع الويب) لا يزال يفشل إلى حد ما ، على الرغم من أن كل شيء يبدو أخضر. أيه أفكار؟

فشل تحميل حزم deb المحورية إلى community في الملف elektra_0.9.3.orig.tar.gz . من المحتمل أن تكون مشكلة إذن في الملف. سأزيله من الدليل في الوقت الحالي وأتركه يُعاد إنشاؤه في الجولة التالية.

بطريقة ما إذا فشل sshPublisher لا يضبط المسرح إلى اللون الأحمر.

ربما نحتاج إلى تكييف cronjob الحالي لإضافة العلم -a؟

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

سيكون Jenkins CI والسجل الموجود على a7 غير متصل بالإنترنت لترحيل صورة برج المراقبة إلى إصدار جديد. يجب أن يستغرق دقيقتين فقط.

تحرير: تم إجراء التحديثات وعاد Jenkins CI للعمل مرة أخرى

سينزل جينكينز والوكلاء لفترة وجيزة للحصول على تحديث.

تحرير: تم تحديث كل شيء وتشغيله مرة أخرى. كنت بحاجة لتصحيح مشكلة حيث كان a7 يستخدم حزم ديبيان الممتدة بدلاً من باستر. أنا أيضا قمت بتنظيف بعض المساحة.

الإصدارات أخفقت نظرًا لعدم وجود مساحة على a7 .

بناء البنية التحتية لن تكون متاحة لبضع دقائق للصيانة.

بناء البنية التحتية متاح مرة أخرى.