Libelektra: Bangun barang Server

@markus2330

Baru saja mendorong beberapa perbaikan terkait sistem build. Tetapi Anda juga perlu memperbaiki beberapa paket pada mesin stabil debian Anda:

• Silakan instal qtdeclarative5-dev dari wheezy-backports (Anda dapat menghapus /opt/Qt5.3.0 setelahnya)
• Silakan instal java8 sebagai paket:
  
  
  
  • Gunakan metode ini: http://www.webupd8.org/2014/03/how-to-install-Oracle-Java-8-in-debian.html
  
  
  • Biarkan cmake benar-benar menemukan 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
  
  
  • kill + restart proses Java jenkins lokal. Jika tidak, semua build akan gagal
  
  
  • Opsional: Hapus jdk7
  
  

Terlihat bagus, terima kasih telah memperbaiki masalah itu.

Saya juga melakukan langkah-langkah tersebut pada agen debian-stable.

Untuk mesin lain menginstal qtdeclarative5-dev tidak mungkin, karena bertentangan dengan qdbus yang dibutuhkan oleh kde4. Jadi saya mengembalikan skrip sebelumnya configure-debian-wheezy sebagai configure-debian-wheezy-local.

Saya juga menambahkan langkah-langkah instalasi yang Anda sebutkan sebagai catatan di README.md karena mungkin menarik bagi orang lain.

Terima kasih telah meningkatkan agen!

Hal-hal yang hilang di stable

1.) lateks (+ Saya pikir texlive-latex-recommended juga diperlukan)
lihat 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.) Bisakah Anda menginstal clang (untuk elektra-clang, clang of wheezy tidak akan berfungsi)?
3.) Bisakah Anda menginstal mingw+wine untuk elektra-gcc-configure-mingw?

apt install --no-install-recommends doxygen-latex + dentang + mingw selesai

Mengapa Anda membutuhkan anggur?

Btw, Anda harus mengubah i586-mingw32msvc-X menjadi i686-w64-mingw32-X di Toolchain-mingw32.cmake . Saat ini ini tidak akan bekerja pada tidak stabil.

Terima kasih untuk dok!

wine diperlukan untuk menjalankan binari windows yang dikompilasi silang (mis. exporterrors.exe)

Saya pikir Anda menginstal mingw yang dibuat untuk w64. Dalam paket mingw32, masih ada /usr/bin/i586-mingw32msvc-c++ .

File rantai alat baru untuk w64 tetap dihargai.

Saya menginstal gcc-mingw-w64-i686 yang merupakan build x64 dari mingw dengan i686 sebagai target.
Paket mingw32-binutils tidak digunakan lagi dan tidak tersedia lagi pada kondisi tidak stabil.

Anggur dipasang di kedua wadah.

Sebenarnya, build mingw terikat stabil, jadi itu seharusnya tidak menjadi masalah.

MinGW-w64 adalah garpu di mingw dan merupakan target yang sangat berbeda. Tidak ada yang mengujinya sampai sekarang.

terima kasih telah memasang anggur

Mingw-w64 terlihat lebih unggul. Mungkin sudah waktunya untuk pindah :-)

Kontribusi diterima ;) Saya tidak punya mesin untuk mengujinya.

Saya khawatir Anda mendapatkan anggur yang salah, seharusnya apt-get install wine32

lihat juga http://build.libelektra.org :8080/job/elektra-gcc-configure-mingw/218/console

Tidak.

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

ok, dpkg --add-architecture i386 akan menyelesaikan ini. Tapi tidak bisakah Anda menyematkan pekerjaan mingw/wine ke mesin build Anda? Pengaturan mingw agak istimewa.

Sunting: Saya akan melihat apakah saya bisa mendapatkan elektra build dengan mingw-w64 jadi saya tidak perlu menginstal banyak lib i686.

Masalahnya adalah saya tidak memiliki mesin jessie cadangan dan mingw wheezy tidak tahu C++ 11.

Saya berhasil membuat mingw-w64 berfungsi. Namun std::mutex tidak tersedia karena tidak ada glibc di windows dan std::mutex bergantung pada pthreads. Ada ide?

Wow terima kasih!

Apakah itu menyebabkan kesalahan kompilasi? std::mutex tidak digunakan untuk internal
fungsionalitas, tetapi hanya dalam file header untuk dimasukkan oleh pengguna. Ini digunakan
dalam kasus uji sekalipun.

Salah satu solusi untuk masalah kompilasi adalah menyediakan std::mutex di mingw
kasus melempar kesalahan sistem pada setiap upaya untuk mengunci/membuka kunci. Sebenarnya, saya akan
mengharapkan orang-orang mingw setidaknya memberikan sesuatu seperti itu (mis
beberapa makro diatur, mirip dengan -D_GLIBCXX_USE_NANOSLEEP)

https://github.com/meganz/mingw-std-threads mungkin dengan cara lain. Tapi itu
kemungkinan besar hanya berguna jika semua kasus uji kecuali yang melibatkan std::mutex
sudah berjalan.

Pada dasarnya, ini hanya satu contoh C++ 11 yang tidak tersedia dengan benar.

status mingw sekarang:

• menambahkan dlfcn-win32 sebagai proyek eksternal ke libloader. cara ini cmake memeriksa + mengkompilasi perpustakaan sebagai langkah build tambahan. Saya menautkan arsip untuk menghindari deps dll tambahan.
• menambahkan dependensi winsock2.h/ws2_32.dll ke cpp11_benchmark_thread. diperlukan oleh gethostname()-call

Saat ini saya sedang membangun dengan -static-libgcc + -static-libstdc++ . Kalau tidak, anggur tidak dapat menemukan dll. Mutex tambahan juga tidak dapat dikompilasi. Saya mencoba mingw-std-utas. baru saja mendapat lebih banyak kesalahan kompilasi :-)

Jika saya beralih dari x86_64-w64-mingw32-X ke x86_64-w64-mingw32-X-posix std::mutex mengkompilasi dengan baik, karena pthread stuff didefinisikan. Namun saya mendapatkan ketergantungan tambahan ke libwinpthread-1.dll, yang tidak dapat ditemukan anggur.

Saya pikir taruhan terbaik kami adalah menggunakan x86_64-w64-mingw32-X-posix .

Sekali lagi, saya terkejut bahwa Anda bahkan memiliki masalah ini. Sampai sekarang kami senang ketika kami mendapat libelektra.dll.

Saya tidak bisa mengatakan apa-apa tentang keputusan x86_64-w64-mingw32-X-posix , karena saya tidak menggunakannya dan tidak tahu implikasinya. Saya bertanya-tanya apakah posix-lib seperti itu bahkan ada, saya pikir pendekatan lapisan posix adalah cygwin dan bukan mingw.

Apakah keputusan ini bahkan berpengaruh pada libelektra.dll? Jika hanya untuk kasus uji, tidak ada yang akan peduli (selama server build dapat menjalankannya). Jika kasus uji berjalan, itu akan menjadi manfaat besar. (Lihat #270 di mana unit test mengungkap beberapa bug aneh di Mac OS X)

Sepertinya libwinpthread-1.dll dapat diunduh, saya tidak tahu apakah mereka bekerja dengan anggur? Bisakah Anda juga menambahkannya sebagai proyek eksternal seperti yang dilakukan dengan dlfcn-win32 (sehingga semua dll ditangani dengan cara yang sama)? Jika tidak, jika Anda perlu mengunduh 1 atau 3 dll untuk pengujian mungkin tidak terlalu penting (sekali lagi, saya bukan pengguna, dan tidak memahami konsep penerapan, jika ada, dari windows dll).

@beku Bagaimana menurutmu? Apakah Anda punya waktu untuk menguji build 0.8.13 mingw-w64 terbaru kami di Windows bersama-sama dengan oyranos?

Apakah tes biasanya diaktifkan untuk pekerjaan build mingw? Kemarin semuanya dinonaktifkan.

Ya, mereka dinonaktifkan. Tetapi contoh/benchmark afaik seperti cpp11_benchmark_thread juga dinonaktifkan. Jadi saya pikir Anda mengubahnya dan mengkompilasi lebih dari yang dilakukan sebelumnya.

Saya mengkompilasi seluruh repo dengan C++ 11 diaktifkan. Tidak ada lagi.

Tetapi executable seperti bin/basename.exe yang dibangun dengan -posix berjalan dengan baik selama Anda menyalin dll yang diperlukan ke direktori bin (terima kasih windows karena tidak memiliki RPATH). Saya belum menemukan cara untuk a) biarkan cmake menemukan direktori dll + b) arahkan wine ke direktori dll.
Saya pikir tautan statis akan berfungsi tetapi kemudian build gagal dengan simbol duplikat selama menautkan elektra dll. Karena dll sudah memiliki simbol yang disertakan.

@ markus2330 Saya berhasil mendapatkan elektra untuk dikompilasi dengan mingw + berjalan dengan anggur tanpa menyalin dll. Triknya adalah selalu mengaktifkan tautan statis untuk objek yang dapat dieksekusi DAN dibagikan ( CMAKE_SHARED_LINKER_FLAGS / CMAKE_EXE_LINKER_FLAGS => " -static ").

Untuk mengatasi simbol duplikat, saya telah menambahkan skrip versi untuk libelektra dan libelektratools. Dengan cara ini hanya simbol kami yang diekspor.

Ini bekerja sangat baik. misalnya

$ 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

Bahkan bin/cpp11_benchmark_thread.exe berfungsi.

Hal-hal lain hanya crash:

$ 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)
[...]

Saat ini saya hanya menambahkan hal-hal skrip versi tanpa memikirkan kompiler lain. Haruskah saya melanjutkan pekerjaan saya atau tidak tertarik?

crash di src/plugins/wresolver/wresolver.c karena pk->nama file NULL

pk bertipe resolverHandles.user

Saya mencoba melihat plugin tetapi saya gagal memahami for-loop di elektraWresolverOpen . Loop memanggil elektraWresolveFileName --> elektraResolve{Spec,Dir,User,System} yang semuanya malloc resolverHandle->filename dan karenanya membocorkan memori.

Terima kasih telah menunjukkan hal itu! Kode jelas rusak sejak diperkenalkan di c87ae8e87a716b02b2c7ed790ad56a89d95547a9
Selama perulangan saja dan selalu pegangan sistem diinisialisasi. Hal ini menyebabkan crash ketika namespace lain digunakan.

Saya memperbaikinya di
edb4d50856bb5331749220de5a83fa2062624a9d

Tentang melanjutkan pekerjaan: Di satu sisi, alangkah baiknya jika hal-hal yang dikompilasi juga berjalan. Di sisi lain, rilis harus dilakukan akhir pekan ini, jadi permintaan tarik akan segera menjadi penting (setidaknya harus ada peluang lingkaran umpan balik singkat, misalnya apa yang sebenarnya dilakukan skrip versi)

Tapi imho itu cukup jika hanya satu varian (kompilasi statis) yang berfungsi. Senang melihat alat kdb berjalan!

Di mana saya dapat menemukan edb4d50856bb5331749220de5a83fa2062624a9d?

edb4d50856bb5331749220de5a83fa2062624a9d didorong sedikit kemudian.

Versi gcc mana yang diinstal pada debian-unstable-mm?

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

mengatakan tidak ada gcc-5.2

Bisakah Anda menginstal kompiler sebanyak mungkin?

Dalam beberapa masalah atau PR saya telah mengatakan bahwa saya telah menghapus semua kompiler kecuali yang terbaru.
Sunting: gcc 4.9 pada stabil, 4.9 + 5.x (default) pada tidak stabil

Silakan lakukan tes semacam ini (saya merasa sangat tidak perlu) di wadah Anda sendiri. Lagipula milikku tidak akan tinggal selamanya.

Saya belum membaca itu. Mereka mungkin memiliki masing-masing 50MB. Bisakah Anda menginstalnya lagi dan menjawab pertanyaan pertama?

Mungkin aku sudah memberitahumu dalam pertemuan kita. Tapi aku sudah pasti memberitahumu.

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

Biner khusus versi disebut gcc-5. Tidak ada paket terpisah untuk versi minor lagi. Jadi multiconfig-gcc Anda dengan tingkat detail ini agak usang. Saya sarankan menghapus gcc 4.7 dan mengganti gcc-5.2 dengan gcc-5 dan selesai.

Satu-satunya kompiler tambahan yang tersedia yang belum saya instal adalah gcc-4.8. Dan gcc-4.8 telah ditandai untuk dihapus.

Terimakasih atas infonya! Sepertinya masa kejayaan banyak kompiler yang tersedia sudah berakhir.

Saya memperbaiki multiconfig-unstable.

Saya akan menutup untuk saat ini, terima kasih untuk pengaturan agen yang sangat baik.

Halo, jessie (stabil) membutuhkan beberapa paket lagi. Bisa tolong instal:

• [ ] akar palsu
• [ ] gpg (+ buat kunci untuk Autobuilder [email protected])
• [ ] reprepro (mungkin sudah terinstal, skrip tidak berjalan sejauh ini)

fakeroot terpasang, gpg + repropro sudah terpasang.
Bisakah Anda mengirimkan saya kunci gpg Anda yang sudah ada? Jadi kedua mesin build memiliki hal yang sama

Tidak apa-apa untuk memiliki kunci gpg yang berbeda. Saya tidak yakin apakah pengaturan saat ini menggunakannya sama sekali, jadi tunggu dulu jika http://build.libelektra.org :8080/job/elektra-git-buildpackage-jessie/2/ gagal.

• debhelper + libsystemd-journal-dev diinstal
• python-dev adalah ketergantungan yang salah. itu harus python2.7-dev atau python3-dev atau keduanya
• mengapa kita membutuhkan dukungan python?

Terima kasih untuk instalasi!

python-dev tersedia untuk Jessie, dan python-support , juga. Silakan instal.

Saya mengujinya secara lokal, ketika paket-paket ini diinstal, itu dibuat untuk jessie.

Tentu, ini tersedia tetapi ketergantungannya salah. python-dev bergantung pada python2.7-dev yang _tidak_ cukup. Sebagai gantinya python2.7-dev + python3-dev diperlukan.

python-support tidak diperlukan sama sekali.

Saya tidak tahu mengapa dependensi dipilih dengan cara ini, sebagian besar pengemasan dilakukan oleh @iandonnelly selama gsoc.

Ya, paket juga harus diperbarui untuk membuat binding python3. Saat ini, itu tidak dilakukan. Namun demikian, Anda dapat menginstal python3-dev, sehingga build tidak akan rusak (ketika binding+plugin python3 ditambahkan ke paket debian).

Itu tidak berarti mereka benar :-) - Saya cukup yakin tentang deps python-dev.
Bisakah Anda menggantinya dan menghapus dep dukungan python?

python3-dev dan python2.7-dev sudah diinstal. Kalau tidak, tidak ada ikatan yang akan dibangun.

Omong-omong. paket debian resmi dari @pinotree hanya membangun python3. Akan membuang-buang waktu untuk memperbaiki apa yang ada di cabang "debian" kami, bagaimanapun juga pekerjaan @pinotree lebih unggul.

Ketika saya menemukan waktu, saya akan memperbarui cabang "debian" kami dengan apa yang telah dilakukan @pinotree dalam paket resmi. Dia sudah mengizinkan kami melakukannya. Saya akan menunggu pembaruan qt-gui, saat ini tidak ada terburu-buru untuk berubah. Dan memiliki dukungan python2 akan menjadi penting untuk satu instalasi (di mana cheetah digunakan, yang tidak akan bekerja dengan python3).

Saya tidak pernah mengatakan saya akan menghapus paket python2. Yang saya katakan adalah python-dev adalah ketergantungan yang tidak akurat. Kami membutuhkan versi eksplisit. Jadi pythonX-dev adalah dep yang benar untuk digunakan.

Semoga pinotree mengatasi ketergantungan dengan benar.

Btw, cheetah sudah mati. Jangan gunakan itu.

Oke, diganti. Harap kembalikan b7c266b36b0ab0fad9120e67a457b580c7c44690 dan instal dukungan python jika memang diperlukan.

Saya yakin pinotree melakukannya dengan benar ;)

Dan tertulis: dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
http://community.markus-raab.org :8080/job/elektra-git-buildpackage-jessie/3/console

terpasang

python-dev adalah ketergantungan yang salah. itu harus python2.7-dev atau python3-dev atau keduanya

• python-dev menginstal paket pengembangan untuk versi default Python 2; sejak Wheezy, ini adalah Python 2.7
• python3-dev menginstal paket pengembangan untuk versi default Python 3; Python 3.2 di Wheezy, 3.4 di Jessie, dan sejauh ini masih 3.4 di Stretch (saya kira akan segera menjadi 3.5)

Jadi, jika Anda ingin membangun versi default Python 2/3, gunakan masing-masing python-dev / python3-dev , bukan versi pythonX.Y-dev (yang perlu Anda gunakan saat Anda secara eksplisit ingin versi Python yang tepat diinstal, meskipun bukan satu-satunya yang diinstal pada sistem, dan bukan yang default). Menggunakan keduanya adalah apa yang saya sarankan.

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

Menurut teks ini python-dev pasti dapat bergantung pada python3 dalam waktu dekat

Lebih jauh lagi: Tidak akan pernah ada versi python2 lain. Jadi python2.7-dev akan menjadi paket dev python2 terakhir yang pernah ada.

Bergantung pada python3-dev adalah apa yang saya katakan.

Sekarang hanya kuncinya yang hilang:

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

selesai

Terima kasih!

Silakan ekspor /home/jenkins/repository melalui http.

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

→ http://194.117.254.29/elektra-stable/

@manuelm Bisakah Anda menginstal ronn pada agen? (diperlukan untuk menghasilkan halaman manual)

apt-get install ruby-ronn

selesai

Terima kasih, paket jessie dibuat lagi, dan halaman manual sekarang disertakan!

Silakan instal musl, yaitu

apt-get install musl musl-dev musl-tools

Terima kasih!

musl diinstal dan agen ditingkatkan

Dua hal penting tentang server build:

1. Jangan membuat pekerjaan kosong baru, melainkan duplikat, mereka memiliki pengaturan yang benar (kecuali yang disebutkan di nomor 2.).
2. Kita harus menggunakan klon referensi (di /home/jenkins/libelektra) atau lebih memilih klon dangkal untuk setiap pekerjaan pembangunan (saat ini dilakukan hanya untuk beberapa, misalnya elektra-dentang). Saat ini lalu lintas >300MB pada komit karena banyak pengulangan yang tidak perlu.

@mpranj Akan lebih bagus jika Anda dapat memperbaiki 2.

@ markus2330 hanya untuk memastikan: Saya hanya harus menerapkan perilaku klon yang sama untuk semua pekerjaan pembangunan seperti di elektra-clang ?

Klon dangkal diterapkan ke semua pekerjaan pembangunan kecuali :

• [ ] elektra-git-buildpackage-jessie
• [ ] elektra-git-buildpackage-wheezy
• [ ] elektra-multiconfig-gcc-stable
• [ ] elektra-multiconfig-gcc-tidak stabil
• [ ] elektra-source-package-test

Pekerjaan ini memeriksa beberapa sub-direktori. Tidak yakin apa yang Anda inginkan di sana, jadi saya akan membiarkan mereka apa adanya untuk saat ini.

Terima kasih! Ya, mereka membutuhkan riwayat dan cabang yang lengkap, klon dangkal tidak masuk akal tetapi repositori klon referensi akan berguna.

Jenkins telah diperbarui ke 1.651.2. Juga semua plugin telah diperbarui.

Saya akan tetap membuka masalah untuk repo klon referensi. Kita juga harus memiliki "pekerjaan cron" yang memperbarui repo dari waktu ke waktu, idealnya menggunakan jenkins itu sendiri.

Jenkins berhenti membangun beberapa pekerjaan (sejak pembaruan tampaknya). Gagal dengan
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Terimakasih atas infonya. Saya mencoba menurunkan versi pembuat permintaan github dari 1,31 ke 1,14.

Sekarang sepertinya macet saat mengatur status build untuk komit Github. Itu memperingatkan bahwa ini sudah usang dalam konfigurasi.

Saya juga mencoba untuk menurunkan versi setiap plugin dengan *git* dalam namanya, tetapi kemudian masih ada kesalahan (kesalahan aneh terkait dengan Plugin Mailer, downgrade dari Plugin Mailer tidak membantu). Jadi saya memperbarui semuanya ke versi terbaru lagi. Masalahnya tampaknya merupakan masalah yang diketahui di hulu:

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

Saya berharap mereka akan segera memperbaikinya.

Pertanyaan lain: Apakah ada yang tahu cara menjalankan banyak pekerjaan untuk setiap PR? (Saya ingin menjalankan elektra-mergerequests-stable dan elektra-mergerequests-unstable)

Pekerjaan elektra-test-bindings berfungsi dengan baik dengan build berparameter (seperti yang juga dijelaskan dalam tiket upstream). Tidak bisakah kita mengalihkannya ke build berparameter? Bug telah dilaporkan ke hulu untuk sementara waktu, saya tidak melihatnya segera diperbaiki.

Ide bagus, kita bisa mengubah semua pekerjaan PR ke build parameter, sebenarnya hanya memiliki kelebihan. Ini memungkinkan kita untuk menjalankan pekerjaan secara manual dengan menentukan cabang juga. Dan itu juga dapat digunakan untuk pekerjaan membangun biasa.

Idealnya, setiap pekerjaan juga dapat dieksekusi oleh PR github. (Kecuali yang khusus untuk tugas non-PR yang memperbarui dokumen atau cakupan cabang master)

Kerugian dari konfigurasi elektra-test-bindings adalah hanya melakukan polling dan membutuhkan waktu cukup lama hingga mulai dibangun (hingga 5 menit). Saya tidak ingin mengaktifkan "Gunakan kait github untuk pemicu build", namun, untuk tidak merusak pekerjaan build.

Omong-omong. apakah Anda yakin bahwa opsi "klon dangkal" tidak apa-apa untuk pekerjaan pembangun pullrequest github?

Saya bertanya-tanya bagaimana github memilih pekerjaan build yang digunakannya untuk PR baru. Mengapa elektra-test-bindings dan elektra-ini-mergerequests tidak pernah dipilih untuk PR baru? Mengapa terkadang elektra-mergerequests-unstable dan terkadang elektra-mergerequests(-stable)?

@manuelm apakah Anda punya ide?

Omong-omong. entah bagaimana komunikasi pekerjaan build yang sudah selesai dan github sangat terganggu (bahkan untuk elektra-test-bindings). Sekarang tertulis di hampir setiap build "Beberapa pemeriksaan belum selesai".

Kerugian dari konfigurasi elektra-test-bindings adalah hanya melakukan polling dan membutuhkan waktu cukup lama hingga mulai dibangun (hingga 5 menit).

Dan ini menjadi masalah karena? Pengujian memakan waktu lebih dari 5 menit pula.

Mengapa elektra-test-bindings dan elektra-ini-mergerequests tidak pernah dipilih untuk PR baru?

Mengapa harus? elektra-test-bindings dipicu oleh "Frase pemicu" saja. Tidak tahu apa itu elektra-ini-mergerequests .

Mengapa terkadang elektra-mergerequests-tidak stabil dan terkadang elektra-mergerequests-stable?

-stable/-unstable baru? Saya tidak yakin memicu banyak pekerjaan per PR baru adalah mungkin. Saya akan melakukan subjob.

Btw saya sudah mengatakan ini beberapa kali tapi saya pikir jumlah pekerjaan semakin konyol dan tanda konfigurasi yang kacau. Tetapi mengkritik selalu lebih mudah daripada memecahkan sesuatu.

5 menit adalah masalah ketika Anda ingin men-debug server build. Dan saya masih berharap kita mendapatkan tes pertama yang cepat, memakan waktu sekitar 5 menit.

Ahh, oke, saya melewatkan opsi "Hanya gunakan frasa pemicu untuk pemicu build". Konfigurasi untuk pembuat permintaan github benar-benar berantakan.

Seseorang berbicara tentang proyek github di mana mereka memiliki banyak pekerjaan yang berjalan untuk setiap PR. (Ditampilkan satu per satu)

Apa itu subpekerjaan? Apakah yang Anda maksud: multi job

Seseorang berbicara tentang proyek github di mana mereka memiliki banyak pekerjaan yang berjalan untuk setiap PR. (Ditampilkan satu per satu)

Anda harus menambahkan dua layanan di github.

Apa itu subpekerjaan? Apakah yang Anda maksud: multi job

Ya multi pekerjaan.

btw, bagaimana dengan https://docs.travis-ci.com/ ? Travis memiliki dukungan untuk OSX.

Saya tahu itu tidak akan menggantikan jenkins tetapi mungkin menggantikan PR/pada setiap build komit. Jenkins masih bisa melakukan beberapa compiler/etc.. testing.
Sunting: Travis bahkan memiliki gcc + dentang.

Setuju, akan menarik untuk menggunakan daya/listrik CPU mereka secara gratis karena elektra adalah open source.

Kemungkinan koneksi antara github dan jenkins sebenarnya adalah 1:1. Di layanan github saya memasukkan http://build.libelektra.org :8080/github-webhook/ dan saya tidak menemukan cara untuk membuat URL lain di jenkins. (Saya hanya menemukan cara menentukan penggantian, tetapi ini tidak membuat URL baru).

Di https://github.com/janinko/ghprb/issues/142 mereka membahas bahwa itu harus "berfungsi"? (Tanpa menambahkan beberapa layanan)

Masalah sha1, bagaimanapun, harus diselesaikan sekarang. Itu rusak karena Jenkins memperkenalkan pengukuran keamanan baru yang memangkas variabel lingkungan yang tidak diketahui. Aku tetap seperti yang disarankan (menambahkan -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 ke /etc/default/jenkins).

Tentang penggunaan server build tambahan: Ya, silakan. Ini juga memecahkan masalah beberapa pekerjaan build untuk satu PR;) Saya tidak pernah menggunakan travis-ci, jadi tidak bisa mengatakan apa-apa tentang itu. Saya memberikan izin bahwa travis memiliki akses ke ElektraInitiative.

Pembuatan travis pertama: https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
Saya pikir kita perlu beberapa file yaml agar travis tahu apa yang harus dilakukan.

Dan saya menemukan cara melakukan beberapa pekerjaan jenkins per PR, diperlukan konteks yang berbeda untuk setiap pekerjaan build. Pada pertemuan berikutnya kita membahas apa yang harus dilakukan oleh pekerjaan "cepat" dan pekerjaan membangun lainnya.

Saya sedang mengerjakan travis (atau memeriksa beberapa hal)

Selamat bersenang-senang. Travis juga menambahkan layanan github, jadi saya rasa PR juga akan dibuat dengan travis.

Aku sudah bersumpah dengan keras

-- TIDAK dapat menemukan JNI (hilang: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
-- Kecualikan Plugin jni karena jni tidak ditemukan

Saya tidak dapat mengkonfigurasi plugin Java dengan benar. Namun binding Java berfungsi. Di debian tidak stabil. Ada ide? Melihat modul cmake tidak banyak membantu.

Sunting: /usr/lib/jvm/java-8-openjdk-amd64/include/linux/jni_md.h , /usr/lib/jvm/java-8-openjdk-amd64/include/jawt.h dan /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h sudah ada

Sunting 2: Mengerti. JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/ ....

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

Debian tidak stabil dibangun di dalam wadah buruh pelabuhan. Tapi membangun membutuhkan waktu lama.
Ada ide bagus?

dentang seringkali lebih cepat mengenai waktu pembuatan, tetapi saya pikir pemasangan dependensi adalah yang membutuhkan banyak waktu

Apakah tidak ada gambar buruh pelabuhan debian yang lebih minimal daripada yang digunakan? Tampaknya banyak paket yang diinstal yang seharusnya tidak diperlukan.

@sirblackheart Apa yang membuatmu berpikir seperti itu? https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm mungkin dist-upgrade. banyak paket diperbarui yang khusus desktop seperti wayland

Tidak. pemutakhiran dist berlangsung singkat. mungkin sebentar. sekitar 50% dari waktu yang dibutuhkan dengan menginstal build deps.

Saya mendorong gambar build ke hub.docker.com sekarang. Harapan itu akan mempercepat segalanya. Tapi gambarnya punya 1.9gb

Waktu berlalu 14 menit 8 detik

Tidak yakin apakah kita bisa melakukan jauh lebih baik

seperti yang saya katakan, dentang mungkin membuat kita 2-3 menit. setidaknya itu untuk proyek aseprite
https://travis-ci.org/aseprite/aseprite

Akan sangat berguna untuk memiliki kedua kompiler.

Baru punya ide saat menyiapkan hal-hal kerja: Bagaimana jika kita mengekstrak jalur semua komit dalam permintaan Push dan membuat binding/plugin hanya jika terpengaruh? misalnya

• perubahan cmake/* memicu semuanya (plugin + binding)
• perubahan dalam src/bindings/foo memicu binding foo
• ubah src/plugins/foo memicu plugin foo
• ubah semuanya tidak mengkompilasi plugin + binding apa pun

Kami masih memiliki jenkins full build harian/dua kali sehari.

@manuelm ide bagus, @tom-wa akan menulis skrip seperti itu, dapatkah Anda membuat masalah baru untuk ini?

@mpranj : Pengingat: tambahkan build Mac OS X ke travis dan tambahkan build mingw ke PR. (*BSD tampaknya lebih berusaha)

@ markus2330 sekarang saya mengerti pendekatan buruh pelabuhan @manuelm , travis tidak akan mendukung ubuntu 16.04 hingga tahun depan sehingga buruh pelabuhan diperlukan untuk mendapatkan semua dependensi yang tidak dimiliki ubuntu 14.04 = swig3.0 libsystemd-devel.

Maaf saya tidak bisa menghadiri rapat hari ini. Di tempat kerja kami masih mempersiapkan peluncuran perangkat lunak besar hari ini, jadi saya tidak bisa meninggalkan kantor. Tapi dalam waktu singkat saya bisa menjawab e-mail.

Saya sudah mulai menambahkan build OS X untuk travis 2 hari yang lalu: https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
Build ada di sini: https://travis-ci.org/manuelm/libelektra/builds/130898079
Buka hal-hal di sini:

• [ ] cryto_openssl gagal dikompilasi
• [ ] tes binding gagal
• [ ] bukan jawa

Saya senang jika ada yang menganggap pekerjaan saya dari sini. Saya tidak memiliki OS X dan menunggu travis untuk memeriksa sistem OSX menyimpulkan dengan sangat cepat.

re: docker: Ya, versi ubuntu default travis tidak berfungsi dengan baik. Bahkan cmake terlalu tua.
Mengambil gambar buruh pelabuhan yang diunggah hanya membutuhkan waktu sekitar 3 menit. Dan menambahkan lebih banyak gambar bukanlah hal yang sulit. Jadi saya pikir itu cara yang bagus untuk mengatasi semua jebakan yang dimiliki lingkungan travis linux default (atau mungkin setelah pembaruan).

Saya belum menemukan cara yang baik untuk mengintegrasikan fase build dan test yang berbeda dari libelektra (cmake + make + make test) dengan docker (build + run) + travis (before_install, before_script, script). Kontainer Docker keluar setelah perintah selesai. Karena wadah buruh pelabuhan dimaksudkan untuk dibuang, Anda tidak dapat melanjutkan setelahnya. Jadi status disk/kompilasi Anda hilang, kecuali Anda memasang direktori lokal ke dalam wadah. Akan terus bekerja di buruh pelabuhan minggu depan.

@manuelm Hebat, Anda melangkah lebih jauh dari yang kami kira. Mac OS X untuk PR dan per komit akan sangat bagus. Banyak orang menggunakan Mac OS X sekarang dan saya tidak ingin merusak build untuk mereka lagi dan lagi. Dalam pertemuan hari ini @mpranj mengatakan akan mengambil pekerjaan Anda. Apakah Anda ingin membuat PR dengan file travis?

Tidak, karena file travis masih harus dimodifikasi setelahnya. Kalau tidak, itu hanya akan membangun OS X. Saya lebih suka jika @mpranj mengambil file travis saya dan memperbaiki masalah terkait OSX yang tersisa. Saya kemudian akan mengambil file travisnya, mengubahnya menjadi matriks build dan mengintegrasikan linux/docker build + #730 (jika tersedia saat itu)

PS: tolong lakukan pengujian travis di repo dengan spasi nama pengguna. Anda akan melakukan banyak dorongan :-)

mingw64 dibangun di atas PR ditambahkan, seharusnya berfungsi. Maaf atas keterlambatannya. Saya akan memeriksa travis hari ini!

Apakah ada kelemahan dari mengaktifkan pekerjaan build untuk dipicu dengan frasa dalam PR (dengan Github PR builder)?

Saya ingin mengonfigurasi pekerjaan dari #745 sehingga saya dapat menguji apakah saya telah memperbaikinya, tetapi saya dapat menerapkannya ke sebagian besar/(semua) pekerjaan pembangunan.

EDIT: Saya lebih suka tidak secara otomatis memulai semua pekerjaan, kami sudah memiliki beberapa.

Saya pikir itu ide yang bagus jika kita dapat mengonfigurasi setiap pekerjaan untuk dipicu dengan sebuah frase. Saya pikir ada kelemahan kecil (setidaknya untuk elektra-test-bindings): Anda harus memasukkan cabang mana yang ingin Anda bangun dan tidak bisa begitu saja menekan "build job now". Akan sangat bagus jika Anda menemukan solusi untuk itu.

Dan Anda benar tentang bahwa kita sebaiknya mengurangi pekerjaan otomatis.

Sebenarnya ada solusi yang sangat sederhana. Kami menggunakan variabel (env) sha1 untuk membangun PR. Build berparameter meminta Anda untuk menentukan nilainya, apakah nilai default disetel atau tidak.

Solusi: atur variabel-env sha1 ke master (dalam konfigurasi jenkins itu sendiri) dan nonaktifkan build berparameter. Jika tidak ada keberatan untuk mengatur variabel, ini akan menyelesaikan persis apa yang Anda sebutkan di atas @ markus2330.

Saya sudah mengaturnya, jadi Anda bisa menekan tombol build itu misalnya elektra-mergerequests dan itu akan mulai membangun master.

Ya, ini adalah solusi yang sangat bagus, saya menyukainya. Itu juga akan memungkinkan kami untuk membangun cabang rilis dengan satu sakelar (jika kami membutuhkannya di masa mendatang). Sampai saat itu "master" selalu menjadi pilihan yang tepat jika tidak dieksekusi dari dalam PR.

Saya pikir itu juga akan memecahkan masalah variabel lingkungan yang difilter, yang kami miliki sebelumnya.

Kemudian kita juga dapat berpikir tentang mengurangi pekerjaan build (tidak ada duplikasi untuk pekerjaan bulid -mergerequest) dan skema penamaan baru yang konsisten. (Saran dapat dilakukan di sini.) Mungkin ada satu masalah terbuka: Saat ini kami membangun cakupan, dokumen,.. untuk PR dan master dan menyalinnya ke tempat terpisah. Jika kami menggabungkan pekerjaan build, kami memerlukan cara untuk membedakan dalam pekerjaan master/PR-pekerjaan untuk menyalin cakupan, dokumen ke tempat yang berbeda.

Saya hampir selesai menerapkan ini ke semua pekerjaan (tetapi server _just_ menjadi sangat lambat).
Tidak berlaku untuk pekerjaan yang membuat wildcard ** (doc dan beberapa lainnya, tetapi sangat sedikit)

Anda selalu dapat menghentikan pekerjaan build saat Anda ingin mengerjakannya jika Anda memulai ulang nanti (kecuali dalam waktu rilis). Biasanya, jenkins sendiri yang menjadi penyebab lambatnya mesin. Saat ini rsync dari cadangan mungkin menjadi masalah, tetapi ini mendesak.

Ya tidak masalah sama sekali, itu harus dilakukan tetapi saya akan melakukan beberapa pemeriksaan terakhir.

Berita @ElektraInitiative/elektradevelopers:

• seperti yang disebutkan hampir _semuanya_ dapat dibangun sekarang dari PR dan/atau hanya menekan tombol build
• frase pemicu selalu merupakan nama pekerjaan tanpa awalan elektra- . (mis. elektra-clang: jenkins build clang please) Saya tidak mengubah jenkins build please dan frasa lama lainnya karena alasan warisan
• pesan status build github selalu persis dengan nama pekerjaan build

Terima kasih, bagus! Harap perbarui doc/GIT.md sehingga semua orang tahu frasa mana yang berfungsi sekarang.

(Saya harap @mention berfungsi untuk satu pesan dan tidak semua orang membaca setiap pesan yang kami tulis di sini)

Mac OS X untuk xcode 6.1 build tampaknya rusak:
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

Saya memicu re-build untuk yang itu tetapi bagi saya sepertinya kegagalan travis sementara.

Bisakah Anda mendokumentasikan cara memicu ulang build untuk PR? Aku tidak tahu itu mungkin.

Langsung di travis-ci.org, menggunakan tautan Anda di atas:

Saya ragu ini layak untuk dokumen tetapi saya tetap bisa melakukannya.
Build masih tidak berfungsi semata-mata karena git checkout. Saya tidak berpikir ini adalah kesalahan kita.

Ah. Saya pikir Anda menggabungkannya sebelum build dipicu/dimulai di tempat pertama.
Ketika saya membangun kembali PR lain yang sebelumnya sukses, itu juga rusak.

Ini lebih merupakan masalah travis daripada yang lainnya.

Oke, terima kasih telah menyelidiki.

@manuelm debian-stable-mm tampaknya tidak dapat dijangkau (untuk jenkins dan untuk saya dari jaringan TU). Bisa tolong selidiki?

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..

Sepertinya seseorang menghentikan wadahnya. Aku sudah memulainya lagi.

btw, mulai besok pagi saya akan berada jauh dari rumah sampai tanggal 1 Agustus. Saya masih dapat dihubungi melalui email tetapi diperkirakan akan tertunda sebentar.

Terima kasih atas perbaikan cepatnya! Jadi saya kira Anda juga tidak akan berada di sini untuk pertemuan berikutnya.

Ya

Beberapa pekerjaan memiliki kesalahan:

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.

misalnya http://community.markus-raab.org :8080/job/elektra-icheck/lastFailedBuild/console http://community.markus-raab.org :8080/job/elektra-doc/lastFailedBuild/console

Mungkin disebabkan oleh pembaruan jenkins atau @KurtMi membuat cabang kdb_import_man ?

Catatan untuk saya sendiri: cppcms perlu diinstal.

Maaf untuk cabang, saya membuat PR langsung di halaman github.

Apakah lebih mudah membuat PR dengan cara ini? Bukankah github menawarkan untuk menghapus cabang setelah digabungkan?

Perubahannya sangat minim, jadi saya jadi malas. Untuk perbaikan yang sangat kecil ya, tetapi ternyata cabang tidak akan dihapus setelahnya. Saya belum melihat cabang hapus setelah digabungkan.

Saya pikir build yang tidak stabil rusak:

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

Log lengkap

@KurtMi tidak stabil lagi (di antara sebagian besar build), tetapi kesalahan Walk tetap ada pada beberapa pekerjaan build yang lebih sederhana. Sepertinya cabang masih tersedia di suatu tempat, mungkin dalam cache di server build?

 > 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 Mungkin kita harus menambahkan lebih banyak skrip di sumber, ini akan memungkinkan pembaruan yang lebih mudah untuk setiap pekerjaan pembuatan. Di #806 kami menemukan bug lain dengan spasi di direktori build, jadi kami harus menambahkan secara global (untuk setiap pekerjaan build) menambahkan spasi di direktori build. Saya lebih suka jika kita dapat menambahkan skrip jenkins-setup yang mengekspor beberapa variabel yang berguna (seperti export HOME="$WORKSPACE/user space ) dan tidak

mkdir "build space"
cd "build space"

Selanjutnya kita harus membuat pekerjaan build yang memperbarui satu repo global. Tugas individu lihat di atas.

Repo global pasti dapat membantu mengurangi bandwidth. Membangun skrip di sumber juga bisa menjadi ide bagus, setidaknya mereka akan dilacak oleh git.

Saya bukan penggemar ruang di jalur, tapi tentu saja.

build cepat di passwd rusak?

Pekerjaan build cepat menjengkelkan, saya mencoba menghapus kdberrors.h di setiap build dan melihat apakah itu berfungsi lebih lancar. Dalam jangka panjang, proposal @manuelm di #730 adalah solusi terbaik: kita hanya perlu memeriksa bagaimana sumber diperbarui, dan berdasarkan ini lakukan pengukuran yang sesuai.

Saya pikir #894 memperbaiki build cepat juga, saya akan mengomentari baris yang menghapus kdberrors.h.

Beberapa pekerjaan rusak, misalnya pekerjaan html doc.

@mpranj Apakah Anda punya waktu untuk melihatnya?

@markus2330 Selesai. Kegagalan build yang tersisa tampaknya tidak terkait dengan sistem build.

@mpranj Terima kasih! Apa yang Anda lakukan untuk memperbaikinya? Saya rasa akan bermanfaat jika disini kita kumpulkan juga solusi untuk membangun masalah server.

Saya mengubah "Manajemen Kode Sumber"> "Git"
Nilai "Penentu Cabang" "**" menjadi "${sha1}"

Ini juga yang kami gunakan di pekerjaan lain. Ini memungkinkan untuk memicu tombol build by (default cabang untuk dikuasai) atau oleh github PR builder (sha1 dari komit).

Saya ingat mengatur variabel ENV "sha1" menjadi "master" sekali. Tampaknya hilang sekarang, tetapi pekerjaan berfungsi dengan baik jadi mari kita abaikan itu.

Saya pikir kita akan dapat mempercepat pembangunan lebih banyak dengan menggunakan Object Libraries lebih sering. Banyak file objek dikompilasi beberapa kali. Kita hanya perlu memastikan bahwa flag kompilasi adalah sama untuk setiap tempat kita menggunakan pustaka objek, tapi saya rasa ini seharusnya bisa dilakukan dengan mudah.

Contoh di mana itu bisa membuat perbedaan besar adalah KDB menurut saya.

@Namoshek Harap hanya memposting build _server_ di sini, bukan tentang sistem build secara umum. Pustaka objek sudah digunakan untuk plugin, tetapi untuk varian yang berbeda, pustaka objek yang berbeda tetap diperlukan (karena flag kompiler yang berbeda). Tapi tolong laporkan saran konkret sebagai masalah terpisah (Maksud Anda alat kdb?).

Jenkins ditingkatkan ke 2,7, semua plugin ditingkatkan, plugin yang direkomendasikan ditambahkan:

• Pipeline (instalasi sepertinya gagal?)
• Plugin Folder Organisasi GitHub

dan beberapa plugin dihapus:

• Cabang API
• CVS/SVN (tampaknya tidak lagi penting)

Selain itu, Ruby-dev telah diinstal pada setiap agen.

Saya memperbarui "Masalah Saat Ini" di posting teratas. Penting bahwa Elektra juga mengkompilasi tanpa dependensi apa pun yang diinstal, jadi kita harus memeriksanya dengan agen server build yang tidak memiliki dependensi apa pun yang diinstal (kecuali cmake dan build-essential). Namun, agen pembangun FreeBSD dan OpenBSD juga penting ;)

@mpranj Apakah Anda tahu apa yang salah dengan elektra-multiconfig-gcc47-cmake-options? Mereka memiliki kesalahan "fatal: reference is not a tree:" di mana-mana. Pekerjaan mereka memiliki "sha1" di konfigurasinya?

Saya membuat multiconfig independen dari kompiler beton (ada cukup banyak pekerjaan build lain untuk kompiler tertentu), sehingga mereka harus dapat berjalan di agen apa pun.

@ markus2330 Tidak tahu. Saya tidak mengubah apa pun dan hanya:

• memicu build dari master secara manual
• memicu build dari github

Kedua bangunan dapat memeriksa pohon dan mulai membangun.
Jadi: Saya tidak dapat mereproduksinya.

Satu ide: travis punya masalah ketika ada PR dan Anda menggabungkannya sebelum travis bisa melakukan kloning. Mungkin hal serupa terjadi dengan elektra-multiconfig-gcc47-cmake-options karena pembangunan di sana membutuhkan waktu ~3 jam.

Mendorong artefak ke doc.libelektra.org berfungsi lagi, Jenkins dan Plugin ditingkatkan.

Saya memperbarui URL server build baru https://build.libelektra.org di Webhooks github. Jadi semoga PR selanjutnya bisa dibangun lagi.

Rumah Jenkins hampir penuh. Tampaknya juga tidak membangun PR.

Rumah Jenkins hampir penuh.

Terima kasih saya mengubah ukurannya.

Tampaknya juga tidak membangun PR.

Apakah Anda tahu apa yang bisa salah di sini? Pemicu manual sepertinya berfungsi?

Menerbitkan dokumen ke doc.libelektra. org:12025 gagal untuk build. Saya me-restart server ssh (pada agen build-homepage) dan sepertinya berfungsi lagi.

Server v untuk *.libelektra.org tampaknya tidak dapat dijangkau. Saya melaporkannya di hetzner.

Alasan untuk mematikan koneksi jaringan dari penampung adalah karena libelektra.org telah disusupi. Lihat #1505 untuk informasi lebih lanjut.

Akan sangat bagus jika kita dapat menambahkan git-build-package untuk stretch, semakin banyak tempat bermunculan di mana kita membutuhkan paket debian yang dibuat untuk stretch.

@BernhardDenner apakah Anda melihat melalui posting teratas? Apakah ada sesuatu yang dapat Anda lakukan dengan mudah? Apakah ada sesuatu yang perlu dipertimbangkan @mpranj saat meningkatkan pekerjaan server build di masa mendatang?

Seperti yang diminta oleh @sansecours saya (sementara) menonaktifkan elektra-mergerequests agar PR tidak selalu mendapatkan kesalahan yang salah. Selanjutnya saya menambahkan untuk @KurtMi

tolong jenkins build gcc-configure-debian-optimizations

@KurtMi Jika Anda perlu mengubah apa yang dilakukan pekerjaan build, cukup ubah skrip/configure-debian-optimizations

@sanssecours sekarang juga memiliki akses ke server build.

Omong-omong. Anda dapat membatalkan pekerjaan jika pekerjaan itu digantikan oleh pekerjaan lain (saat ini ada beban berat). Hanya berhati-hatilah untuk tidak membatalkan pekerjaan untuk PR aktif, jika tidak PR tidak akan menjadi hijau. (Kecuali Anda memulai ulang dengan frasa "jenkins build ... please".)

@sanssecours Jenkins dimulai ulang (kedua kalinya). Bisakah Anda mendokumentasikan di sini jika Anda menginstal plugin baru. (Pembaruan tidak perlu didokumentasikan).

Permintaan untuk memulai ulang juga dapat dilakukan di sini.

Saya mengubah "Periode tenang" dari 2 menjadi 5 untuk memberi lebih banyak waktu untuk menggabungkan beberapa PR dan/atau mendorong komit yang berbeda tanpa membangun kembali secara berulang.

Selanjutnya, saya membuka masalah #1689 yang menjelaskan batas waktu dalam build (saya tidak menambahkannya di sini karena pesan kesalahan yang panjang).

Saya juga memindahkan beberapa tugas usang di atas di bagian baru "Masalah Usang/Tidak Relevan [alasan]:".

Saya memperbarui plugin di server build. Semoga pembaruan memperbaiki masalah yang kami miliki di PR #1698 dan PR #1692.

@ markus2330 Bisakah Anda me-restart server build?

Saya memutakhirkan Jenkins dari 2.73.2 ke 2.73.3 dan memulai kembali Jenkins.

Semoga pembaruan memperbaiki masalah yang kami miliki di PR #1698 dan PR #1692.

Mungkin masalah umum yang tidak terkait dengan kedua PR ini? Semoga sekarang sudah diperbaiki.

Sepertinya JENKINS_HOME hampir penuh .

@markus2330 Bisa tolong

• bersihkan direktori home atau beri tahu saya bagaimana saya bisa melakukannya,
• perbarui Jenkins dan semua plugin yang sudah ketinggalan zaman?

Terima kasih telah ping saya!

Sepertinya sebuah plugin memiliki "kerentanan pembacaan file sewenang-wenang", yaitu "Plugin Keamanan Skrip 1.35".

Saya memutakhirkan semua plugin dan juga memutakhirkan jenkins dari 2.73.3 menjadi 2.89.1.

Selanjutnya, saya mengubah ukuran disk dari 20GB menjadi 50GB.

Kami harus segera memulai ulang server, ada beberapa proses yang tidak dimulai ulang yang mungkin terpengaruh oleh peningkatan perpustakaan, yang mungkin tidak aman saat ini (meskipun tidak terkait dengan jenkins). @BernhardDenner Bisakah Anda melakukan restart (dan melakukan perbaikan jika sesuatu tidak dimulai)?

Harap jangan ragu untuk melaporkan apa pun yang saya rusak selama peningkatan ini.

Server memuat 20 dan hampir tidak merespons. Kita harus berhati-hati dengan "jenkins build all please" dan dalam jangka panjang kita harus memindahkan agen dari server utama.

Saya memutakhirkan ke Jenkins 2.89.2 dan memulai ulang server. Saya akan melaporkan ketika semuanya sudah aktif dan berjalan kembali.

Sepertinya semua agen sekarang terputus dengan kesalahan "The server hostkey was not accept by the verifier callback".

@BernhardDenner Saya melihat

Saya mencoba menurunkan versi ke 2.89.1 dan 2.73.3 tanpa hasil: menghubungkan ke agen masih tidak berfungsi.

Terima kasih banyak kepada @BernhardDenner yang memperbaiki masalah ssh.

Kita harus berhenti memutakhirkan Jenkins tanpa membaca catatan rilis, sepertinya bahkan pembaruan stabil merusak terlalu banyak hal. (Itu bahkan tidak dapat dikembalikan dengan menurunkan versi!)

Saya harus melaporkan kemacetan besar di server build.
elektra-multiconfig-gcc47-cmake-options membutuhkan waktu 14 jam dan
elektra-multiconfig-gcc-stable membutuhkan waktu 4 jam.
Saya tidak yakin apakah itu perilaku baru dan saya sadar bahwa pekerjaan ini bukan pekerjaan pembangunan tunggal, tetapi hambatan ini tidak boleh diabaikan.

Terima kasih telah melaporkan. Idenya adalah untuk mendistribusikan subjob dari pekerjaan ini ke perangkat keras ryzen, sayangnya tidak ada yang punya waktu untuk setup. Jika seseorang tertarik, silahkan hubungi saya.

a7.complang.tuwien.ac.at (ryzen) sepertinya mogok. Saya melaporkan masalahnya. Admin kami diharapkan akan me-restart komputer pada hari Senin.

Saya sementara menonaktifkan inkremental (kesalahan aneh, lihat #1784), admin memulai ulang server ryzen, dan kemudian saya me-restart jenkins (karena Jenkins tidak dapat terhubung ke ryzen dan ada tumpukan besar build ryzen).

ryzen sekarang bekerja lagi dan membangun backlog.

Idenya adalah untuk mendistribusikan subjob dari pekerjaan ini ke perangkat keras ryzen

@ markus2330 Saya perhatikan ada opsi yang disebut Run each configuration sequentially dalam pengaturan matriks konfigurasi dari pekerjaan multiconfig. Mungkin itu akan didistribusikan secara otomatis jika kita hanya menghapus centang ini sehingga membangun beberapa opsi konfigurasi sekaligus, atau sudahkah Anda mencoba ini?

Tidak, saya belum mencobanya, silakan coba.

@ markus2330 dilihat dari antrian server build, ini sepertinya berhasil, saya akan menerapkannya ke gcc-stable tambahan setelah berfungsi untuk gcc-stable-multiconfig

Namun saya perhatikan bahwa ryzen tampaknya tidak menangani pekerjaan itu. Saya pikir ini karena dikonfigurasi untuk hanya menangani pekerjaan yang cocok dengan tagnya dan build multiconfig tampaknya tidak mengatur tag tersebut dengan tepat pada pandangan pertama. Jadi kita harus membuat ryzen mengeksekusi semua yang mungkin atau mengatur lebih banyak tag pada pekerjaan build. Sepertinya ryzen tidak menangani pekerjaan yang tidak memiliki tag sama sekali.

saya akan menerapkannya ke gcc-stable tambahan setelah berfungsi untuk gcc-stable-multiconfig

Terima kasih!

Namun saya perhatikan bahwa ryzen tampaknya tidak menangani pekerjaan itu.

Tidak, tidak tetapi sudah menjalankan banyak pekerjaan lain. Tapi mungkin kita bisa membuat v2 untuk melakukannya?

saya akan menerapkannya ke gcc-stable tambahan

selesai

Tapi mungkin kita bisa membuat v2 untuk melakukannya?

Saya telah mengonfigurasi v2 dan sekarang saya hanya menunggu PR #1806 digabungkan sehingga saya dapat mengizinkan lebih banyak build di atasnya daripada satu. Saya pikir 8 pekerjaan seharusnya baik-baik saja karena ini adalah 8-inti, dengan -j 2 untuk memanfaatkan SMT juga?

Untuk memulai ulang wadah build-v2 jika v2 mogok atau dimulai ulang, cukup ketik . Perhatikan bahwa ini hanya dapat dilakukan jika wadah telah dibuat - ikuti doc/docker/jenkinsnode/README.md untuk petunjuk ini. Kemudian gunakan perintah ini untuk memulai kembali setelah wadah dibuat tetapi telah berhenti:

docker start build-v2

Juga, untuk meneruskan koneksi ssh dari node build baru dari v2 melalui a7 ke dunia luar, saya telah menyiapkan terowongan ssh berikut di a7 (wadah buruh pelabuhan memetakan port ssh ke 22222 di v2):

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

Selain itu, kunci ssh publik dari wadah buruh pelabuhan berubah pada setiap pembuatan ulang gambar dan karenanya harus disesuaikan di server pembangunan juga. Ini tidak diperlukan jika penampung hanya dimulai ulang. Untuk mengetahuinya, masukkan berikut ini di v2:

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

Hanya salin dua hal pertama, jadi algoritme kunci dan kunci itu sendiri, jangan salin informasi pengguna ini di akhir ke konfigurasi ryzen-v2 di jenkins untuk kunci ssh!

v2 sedang down, saya memberi tahu admin. Cukup aneh: a7 dan v2 adalah perangkat keras yang sama sekali baru dan insidennya cukup sering terjadi.

v2 tampaknya kembali dan saya telah memulai kembali wadah build di sana. Jadi semoga kami memiliki build yang lebih cepat sekarang lagi. Selain itu saya telah menambahkan elektra-haskell ke "jenkins build all please" karena saya ingin memiliki haskell build yang stabil untuk typechecker saya, jadi pengujian adalah tambahan yang bagus.

Selanjutnya saya ingin meninggalkan catatan di sini bahwa kami juga ingin membuat node build lain yang menangani build mm yang sekarang tampaknya menjadi hambatan baru di v2 juga.

Terakhir, @markus2330 saya pikir point run bashism checker sudah selesai, karena ini adalah salah satu tes kami yang biasa /testscr_check_bashisms.sh .

Semua node untuk label debian-jessie-homepage||homepage dan agen build debian-wheezy-mr saat ini sedang offline. Memulai ulang agen build tidak berfungsi. Akan sangat menyenangkan jika seseorang dengan SSH atau akses fisik ke node ini dapat melihat masalah ini.

Saya me-restart vservers tetapi me-restart agen di dalam jenkins tidak berfungsi dengan kesalahan "Tidak ada remah yang valid disertakan dalam permintaan". @BernhardDenner Apakah Anda punya ide?

Sepertinya v2 juga turun. Jadi kami memiliki 3 agen non-fungsional

v2 kembali, tapi saya bertanya-tanya mengapa selalu turun? mungkinkah itu terkait dengan proses pembuatan kami?

Mengenai "tidak ada remah yang valid" saya juga melihatnya ketika saya mencoba me-restart agen di v2, tetapi ketika saya mencobanya lagi itu berhasil.

v2 kembali, tapi saya bertanya-tanya mengapa selalu turun? mungkinkah itu terkait dengan proses pembuatan kami?

Tampaknya ini adalah kegagalan kernel/perangkat keras (bahkan sysreq tidak berfungsi saat komputer hang). Penggunaan kami mungkin memicu kesalahan. Komputer berjalan tanpa kesalahan selama beberapa bulan dan sejak kami menggunakannya, kami telah mengalami crash tiga kali.

Saya memutakhirkan kernel dan membersihkan X-server.

Mengenai "tidak ada remah yang valid" saya juga melihatnya ketika saya mencoba me-restart agen di v2, tetapi ketika saya mencobanya lagi itu berhasil.

Terima kasih! Saya sekarang dapat memulai agen beranda lagi.

Selanjutnya, saya menonaktifkan agen debian-jessie-minimal dan pekerjaan pembuatannya. Kita harus membuat wadah buruh pelabuhan untuk pekerjaan minimal, saya menambahkan ini sebagai tugas.

Seperti yang kami terkejut kemarin, server komunitas sedang down karena crash dan cache ARP yang salah mengalihkan IP kami ke server lain. Setelah memulai ulang, semuanya berfungsi kembali, tetapi sinkronisasi serangan masih berlangsung. (Mungkin sangat lambat karena beban yang tinggi.)

Server komunitas memiliki beban hampir konstan 10. Saat ini 13,20 11,29 9,35. Kami benar-benar harus mengurangi pekerjaan yang langsung berjalan di server komunitas dan memindahkan beban ke v1. Ada sukarelawan?

Ada peningkatan Jenkins dari 2.89.2 menjadi 2.89.4. Sayangnya saya tidak menemukan cara mudah untuk melihat Changelog ( apt-get changelog gagal karena ini adalah paket tidak resmi). Adakah alasan untuk tidak melakukan pembaruan ini?

Changelog upstream ada di https://jenkins.io/changelog-stable/
Rupanya 2.89.4 berisi perbaikan keamanan.

Terima kasih telah mencarinya!

Saya memutakhirkan ke Jenkins 2.89.4 dan semuanya berjalan kembali.

elektrahomepage tidak dimulai secara default setelah reboot, saya mengubahnya (/etc/vservers/elektrahomepage/apps/init/mark=default).

Saya juga mengaktifkan pekerjaan build test-docker.

v2 turun, lagi :cry:

Tapi setidaknya a7 tampaknya stabil sekarang.

Saya menginstal clang-format-5.0 pada a7 dan pada node stretch (debian-stretch-mr).

Untuk PR selanjutnya silahkan format ulang sesuai clang-format-5.0.

https://build.libelektra.org/jenkins/job/elektra-clang-asan/ untuk sementara dinonaktifkan.

Kami sedang menyelidiki v2. UEFI dari 6.6.17. Sepertinya crash selalu terjadi di akhir pekan, mungkin ada beban yang lebih tinggi saat itu? Saya akan mencoba mereplikasi pengaturan v1 di v2.

v1 dan v2 aktif dan berjalan dengan kernel yang sama.

@ e1528532 sepertinya jembatan ssh Anda tidak dimulai dan perintah di doc/docker/jenkinsnode/README.md gagal dengan "tidak dapat menyiapkan konteks: tidak dapat mengevaluasi symlink di jalur Dockerfile: lstat /root/Dockerfile: tidak ada file atau direktori seperti itu " dan kemudian "Tidak dapat menemukan gambar 'buildelektra- stretch:latest ' secara lokal". Ini berarti v2 tidak dapat dijangkau saat ini.

@ markus2330 menulis: memindahkan masalah ke #1829

Saya pikir salah satu pembaruan terbaru ke server build rusak elektra-gcc-configure-debian-stretch , yang tidak dapat terhubung ke repositori lagi:

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

.

Saya pikir masalah dengan elektra-gcc-configure-debian-stretch adalah server build ryzen , yang tidak dapat terhubung ke GitHub. Saya mengubah label untuk pekerjaan build dari debian menjadi debian-stretch-mr sesuai. Sekarang pekerjaan membangun tampaknya bekerja lagi .

ryzen, yang tidak dapat terhubung ke GitHub

Sepertinya perbaikan NetworkManager admin kami dengan "maned=true" tidak berfungsi dengan baik. Setelah restart "/etc/resolv.conf" kembali menjadi symlink yang menggantung. Saya memperbaikinya lagi, GitHub harus dapat dijangkau dari ryzen. rzyen v2 sayangnya masih belum dapat dijangkau (jembatan ssh tidak ada).

Elektra 0.8.22 akhirnya dirilis. Saya akan menambahkan tautan ke #676 setelah situs web dibuat, pembuatan situs web membutuhkan waktu lebih dari satu jam. Mungkin kita dapat memindahkan pembuatan beranda ke mesin yang lebih cepat dan hanya menyalin situs web yang dihasilkan ke lokasinya.

Saya pikir kami telah melakukan sesuatu tentang server yang menampung http://build.libelektra.org. Itu sangat lambat dan tidak responsif . Secara pribadi saya tidak peduli jika membangun penuh semua tes membutuhkan waktu lama. Namun, seperti saat ini, dibutuhkan beberapa menit untuk terhubung ke server, jika kita dapat terhubung ke server sama sekali:

<!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>

.

Ya, yang terpengaruh tidak hanya Jenkins tetapi semua yang berjalan di server ini. Bagi saya situasinya sering juga tidak dapat diterima. Sepertinya ada terlalu sedikit RAM. (2GiG swap digunakan)

Jenkins mungkin menjadi alasannya, ada lusinan proses Java yang memimpin daftar di htop. Untuk waktu yang lama kami memiliki cukup RAM dan swap hampir tidak digunakan, dan kami tidak banyak berubah (kecuali memutakhirkan Jenkins dan meningkatkan jumlah pekerjaan pembangunan).

Saya sarankan untuk berhenti menggunakan server komunitas sebagai agen sama sekali. Untuk ini kita perlu v2 kembali tapi @e1528532 tampaknya sibuk. Kami juga dapat menyewa server yang lebih baik tetapi kemudian kami akan membutuhkan seseorang yang memiliki waktu untuk migrasi.

@ markus2330 Bisakah Anda me-restart server build? Saat ini bahkan pekerjaan sederhana seperti elektra-todo gagal.

saya me-restart v2 pada hari Minggu tetapi ternyata sudah turun lagi, jadi kita harus terlebih dahulu mendapatkan v2 stabil sebelum berpikir untuk meletakkan hal-hal lain di atasnya.

Saya me-restart Jenkins dan v2. Jenkins tampaknya berjalan lancar lagi.

@e1528532 Terowongan ssh tampaknya masih tidak berfungsi. Bahkan setelah memulai ulang a7 tidak mungkin terhubung ke v2.

jadi pertama-tama kita harus mendapatkan v2 stabil sebelum berpikir untuk meletakkan hal-hal lain di dalamnya.

Waktu henti utama disebabkan oleh jembatan ssh. Jika v2 mengalami masalah, biasanya dimulai ulang dalam sehari.
Saya sekarang menghapus sisa server X, jadi saya harap v2 sekarang juga stabil. Untuk a7 ini sepertinya triknya (tidak perlu restart untuk beberapa waktu). Tanpa beban pada v2 (yang membutuhkan jembatan ssh), bagaimanapun, kita tidak akan tahu pasti apakah itu stabil.

Bagaimana dengan membagi diskusi tentang perangkat keras (restart) dan perangkat lunak (peningkatan Jenkins)?

Tampaknya ada masalah konektivitas jaringan antara a7 dan v2. v2 aktif dan berjalan tetapi saya masih mendapatkan "Tidak ada rute ke Host". Sepertinya saya tidak bisa memperbaikinya hari ini.

Jaringan v2 mati karena penghapusan instalasi GNOME juga menghapus pengelola jaringan. Kami sekarang memperbaiki jaringan (menggunakan /etc/network/interfaces) dan memutakhirkan ke BIOS/UEFI terbaru. Jadi mudah-mudahan semuanya sekarang stabil.

Omong-omong. ada satu lagi perangkat keras yang bisa kita gunakan melalui ssh bridge... (PCS)

Terowongan ssh tampaknya masih tidak berfungsi. Bahkan setelah memulai ulang a7 tidak mungkin terhubung ke v2.

Ya ini tidak otomatis. Sekarang saya telah mengurus semuanya. Wadah buruh pelabuhan harus dimulai ulang secara otomatis sekarang jika mesin dimulai ulang. Setidaknya saya telah mengatur flag --restart ke "selalu" menurut https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode #37618747

Selanjutnya saya telah membuat pengguna baru bernama "ssh-tunnel-a7-v2" yang tidak memiliki kata sandi yang ditetapkan pada a7 dan v2 (jadi, nonaktifkan otentikasi kata sandi untuk yang itu). Saya membuat sertifikat ssh untuk pengguna di a7 dan menambahkan kunci publiknya ke host yang dikenal di v2. Kemudian saya menambahkan layanan systemd ke /etc/systemd/system/ssh-tunnel-a7-v2.service yang membuka terowongan ssh secara otomatis sebagai layanan systemd menurut https://Gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service . Oleh karena itu, itu juga harus berfungsi ketika server dimulai ulang atau koneksi ssh macet dan tidak lagi bergantung pada saya atau pengguna saya. Karena penggunaan sertifikat tidak ada kata sandi yang harus digunakan untuk koneksi.

Selain itu, v2 dimulai ulang tentu saja dengan konfigurasi otomatis baru ini aktif. Mudah-mudahan itu selamat dari kecelakaan berikutnya (jika ada), secara teoritis seharusnya tetapi kita akan lihat.

Pekerjaan build test-docker selalu gagal, jika Jenkins menjalankan pekerjaan pada 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

. Saya ingin membatasi pekerjaan ke node selain ryzen v2 , tetapi tampaknya opsi untuk langkah ini tidak ada di halaman konfigurasi test-docker . Bisakah seseorang tolong lihat dan perbaiki masalah ini?

Terima kasih melihat ke dalamnya! Apakah mungkin untuk menetapkan beberapa label ke agen? Kemudian Anda dapat menetapkan label unik untuk ryzen v2 dan mengikat pekerjaan itu.

Untungnya, kami akan segera mendapatkan dukungan untuk server build kami :+1:

Apakah mungkin untuk menetapkan beberapa label ke agen?

Sejauh yang saya tahu ya, dimungkinkan untuk menetapkan beberapa label ke agen.

Kemudian Anda dapat menetapkan label unik untuk ryzen v2 dan mengikat pekerjaan itu.

Seperti yang telah saya nyatakan sebelumnya [[1]] opsi "Batasi di mana proyek ini dapat dijalankan" tampaknya tidak ada:

Saya ingin membatasi pekerjaan ke node selain ryzen v2 , tetapi tampaknya opsi untuk langkah ini tidak ada di halaman konfigurasi test-docker .

.

Ahh, saya salah memahami pernyataan Anda sebagai: "Tidak ada cara untuk menulis ekspresi boolean yang memungkinkan saya untuk mengatakan (stabil && !ryzenv2)", bukan berarti tidak ada opsi untuk pembatasan agen sama sekali.

Mungkin ini bisa dilakukan oleh DSL. Saya akan bertanya pada Lukas apakah dia tahu apa yang harus dilakukan.

Hai,

sebagai @sanssecours mencatat ryzen v2 tidak memiliki buruh pelabuhan diinstal tetapi memiliki tag buruh pelabuhan.
test-docker menjalankan membutuhkan node untuk memiliki tag buruh pelabuhan.

Solusi yang mungkin adalah menginstal buruh pelabuhan pada simpul atau menghapus tag dari simpul di jenkins

Solusi yang mungkin adalah menginstal buruh pelabuhan pada simpul atau menghapus tag dari simpul di jenkins

Terima kasih telah memberikan solusi untuk masalah tersebut. Saya baru saja menghapus tag docker dari ryzen v2 . Sejauh yang saya tahu semuanya tampaknya berfungsi sekarang.

Saya memperbarui deskripsi simpul 'ryzen v2' untuk mencerminkan bahwa itu sebenarnya 'hanya' wadah buruh pelabuhan yang berjalan di v2. Karenanya mengapa buruh pelabuhan tidak tersedia meskipun sudah diinstal pada v2.

Juga menambahkan plugin ke jenkins yang memungkinkan visualisasi data build yang lebih mudah (tidak harus mengklik setiap build)

v2 turun lagi, saya melaporkannya.

Saya mem-boot ulang v2 tetapi tidak dapat menghubungkan kembali agen.

Setidaknya kami akhirnya mendapat pesan kesalahan tentang apa yang terjadi sebelum crash (tentu saja tidak ada jaminan bahwa pesan kesalahan ada hubungannya dengan crash):

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

Aneh, sepertinya mesin restart saya berfungsi, baik terowongan ssh dan node buruh pelabuhan dimulai ulang dan saya dapat terhubung ke a7.complang.tuwien.ac.at -p 22222, yang berarti semuanya harus terbuka. Namun entah bagaimana jenkins hanya menunjukkan kepada saya roda pemintal yang tak terbatas untuk beberapa alasan, tidak ada batas waktu, tidak ada apa-apa.

Saya mencoba jembatan ssh manual saya seperti yang kami lakukan sebelumnya, sama. Restart wadah buruh pelabuhan sekali lagi, sama. Jadi sejujurnya saya tidak yakin apa sebenarnya yang salah sekarang tanpa pesan kesalahan, satu-satunya hal yang saya temukan adalah beberapa orang yang tampaknya memiliki bug yang sama (roda berputar tetapi tidak ada pesan) tetapi tidak ada solusi selain me-restart seluruh master jenkins simpul (yang belum saya coba): https://issues.jenkins-ci.org/browse/JENKINS-19465

EDIT: saya mencoba salah satu solusi yang disarankan (setel ulang konfigurasi nama host ke sesuatu yang tidak ada, sambungkan kembali, lalu jenkins menyadari nama host salah, ubah kembali ke nama host yang sebenarnya, lalu tiba-tiba berfungsi tanpa kerumitan lebih lanjut). Jadi saya kira kesalahan ini terjadi alih-alih sesuatu dengan pengaturan restart saya tetapi mari kita tunggu crash berikutnya untuk memastikannya;)

@ markus2330 saya yakin Anda sudah menemukan ini sendiri tetapi pencarian cepat menunjukkan kepada saya bahwa ini mungkin terkait dengan konfigurasi c-state: https://bugzilla.kernel.org/show_bug.cgi?id=196683 , ada beberapa yang disarankan solusi untuk itu

Sepertinya server build ryzen tidak dapat terhubung ke repositori kami :

Gagal mengambil dari https://github.com/ElektraInitiative/libelektra.git

.

konfigurasi dns menggantung lagi. Karena saya tidak sepenuhnya mengerti mengapa
atur cara saat ini saya hanya mengembalikan pengaturan server nama dan
memulai kembali pekerjaan pembangunan buruh pelabuhan.

Pada 12 Maret 2018 pukul 17:03, René Schwaiger [email protected] menulis:

Sepertinya server build ryzen tidak dapat terhubung ke repositori kami
https://build.libelektra.org/jenkins/job/test-docker/162/console :

Gagal mengambil dari https://github.com/ElektraInitiative/libelektra.git

.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-372363457 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEOv-gcB-XWqDbqbRZfRnfnadYjZN21hks5tdpxLgaJpZM4DIApm
.

Karena saya tidak sepenuhnya mengerti mengapa ini diatur seperti saat ini

Saya khawatir tidak ada yang memahaminya. Mungkin server DNS salah dikonfigurasi dan tidak memberikan informasi server nama yang tepat. Untuk v2 kami menghapus pengelola jaringan dan sepertinya resolv.conf sekarang stabil di sana. Jadi salah satu opsi adalah menghapus instalan pengelola jaringan di a7 juga. (dan gunakan /etc/network/interfaces) Tidak ada alasan mengapa v2 dan a7 memiliki pengaturan yang berbeda, itu hanya karena administrasi yang ceroboh.

Idealnya (dalam jangka panjang), kami mengelola keduanya menggunakan Wayang.

https://bugzilla.kernel.org/show_bug.cgi?id=196683 , ada beberapa solusi yang disarankan untuk itu

C6 harus dinonaktifkan tetapi kami akan melanjutkan penyelidikan.

Agen pembangunan baru "ryzen v2 docker" tampaknya tidak menjalankan daemon D-Bus seperti "debian-stable-mm" .

Bisakah seseorang menginstal/memulai atau memberi tahu saya skrip mana yang mengonfigurasi build multiconfig-gcc47-cmake-options sehingga saya dapat menambahkan cuplikan untuk memastikannya dimulai?

@ markus2330 Saya curiga karena ifupdown dan networkmanager diaktifkan, keduanya saling mengganggu. menonaktifkan salah satu dari keduanya pasti akan membantu.

Oke, saya menghapus gnome dan network-manager di a7 agar konsisten dengan v2.

Agen pembangunan baru "ryzen v2 docker" tampaknya tidak menjalankan daemon D-Bus seperti "debian-stable-mm".

Agen pembangunan tinggal di dalam wadah buruh pelabuhan, semoga @ingwinlu atau @e1528532 dapat membantu Anda memulai daemon dbus di sana.

Terima kasih. Seharusnya cukup mudah. Saya memulainya di wadah buruh pelabuhan (Ubuntu 17.10 artful dibangun dari docs/docker/Dockerfile ) dengan perintah berikut:

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

Server build ryzen tidak dapat terhubung ke repositori kami lagi .

Maaf, salahku. Sepertinya menghentikan manajer jaringan sudah cukup untuk merusak sistem.

Seharusnya sudah diperbaiki sekarang. Harap jangan ragu untuk melaporkan masalah lebih lanjut.

@ markus2330 cukup yakin itu akan rusak lagi pada reboot berikutnya

Saya mengambil kebebasan untuk mengulang file /etc/network/interfaces (dan memindahkan konfigurasi antarmuka ke /etc/network/interfaces.d)
yang dikombinasikan dengan penghapusan instalan manajer jaringan semoga tetap stabil

silakan tinjau konfigurasi dan mungkin memicu reboot untuk melihat apakah itu berhasil

@ingwinlu Terima kasih atas perbaikannya, reboot bekerja dengan baik.

Saya menemukan bahwa saya menghapus terlalu banyak paket, jadi saya menginstal Java (openjdk 9 headless dan default-jre) lagi :smile:

@ingwinlu Bisakah Anda membuat dbus berjalan di agen v2? Idealnya tolong juga pindahkan "/home/armin/buildelektra-stretch/Dockerfile" ke beberapa tujuan khusus non-pengguna.

@ markus2330 proposal saya tentang cara melanjutkan dengan lingkungan build sebenarnya meramalkan penghapusan node dockercontainer-on-v2 saat ini dan menggantinya dengan yang mampu buruh pelabuhan (yaitu tidak lagi menunjuk ke wadah buruh pelabuhan di v2 tetapi menunjuk langsung ke v2) .

Setelah itu, kita dapat mengatur pipeline build untuk membangun image itu sendiri dari Dockerfiles yang diperiksa ke dalam repositori untuk menyediakan lingkungan berbeda yang diperlukan untuk pengujian.

Saya dapat memprioritaskan peluncuran gambar buruh pelabuhan berkemampuan dbus ketika saya mendapatkannya, tetapi saya tidak ingin melakukan pekerjaan yang akan segera tidak relevan jika saya tidak harus melakukannya.

Ya, itu masuk akal!

Tujuan jangka panjang dari v2 adalah kita harus membaginya dengan beberapa wadah buruh pelabuhan lain (bukan untuk Elektra), jadi akan lebih baik jika semua bagian kita divirtualisasikan sedemikian rupa sehingga mereka tidak dapat mempengaruhi wadah buruh pelabuhan lainnya. (mungkin docker rekursif atau Xen?) Kita bisa/harus melakukan hal yang sama agar a7 memiliki setup yang identik.

Kami akan terus memiliki akses langsung di mesin tetapi kami harus mengurangi risiko Jenkins dapat membunuh mesin Docker yang tidak ada hubungannya dengan itu.

Untuk beberapa agen kami sudah memiliki setup Wayang. Akan sangat bagus jika kita tidak melewatinya atau bahkan lebih baik: perpanjang pengaturan ini untuk a7 dan v2. Saya harap @BernhardDenner dapat memberi Anda lebih banyak info tentang itu segera.

Build server down lagi .

Omong-omong, kita bisa memindahkan diskusi tentang status server build ke diskusi Tim GitHub , karena topik ini mungkin tidak menarik bagi semua orang yang berlangganan masalah ini.

Ya, seluruh server sedang down, termasuk build server :cry: Dan v2 juga down (independen). Saya memulai ulang v2 dan mengubah opsi C-States di UEFI. Tapi sepertinya ada masalah besar dengan server kami. Semoga kita bisa menggantinya dengan perangkat keras yang lebih baik dengan lebih banyak memori :crossed_fingers:

Diskusi Tim GitHub

Bukankah setiap orang dari ElektraDevelopers diberi tahu jika kami menulis sesuatu dalam diskusi Tim GitHub? Di sini, di edisi ini, setiap orang dapat memutuskan apakah dia ingin berlangganan.

Bagi saya pertanyaan yang masih terbuka adalah apakah kita harus membagi masalah ini menjadi dua masalah: terkait perangkat keras dan terkait Jenkins.

Bukankah setiap orang dari ElektraDevelopers diberi tahu jika kami menulis sesuatu dalam diskusi Tim GitHub?

Sejauh yang saya tahu, ya.

Di sini, di edisi ini, setiap orang dapat memutuskan apakah dia ingin berlangganan.

Itu juga berlaku untuk Diskusi Tim .

Build server sudah aktif kembali. Pengaturan berubah:

• pengaturan xms dan xmx untuk mengurangi jumlah pengumpulan sampah ketika banyak build dalam antrian
• saya perhatikan kami menggunakan polling scm. Saya mencekik poller ke 4 polling bersamaan secara global sekaligus untuk semoga mengurangi sedikit lonjakan yang didapat server saat ini.

EDIT:

* Tetapkan # build ke 30 untuk semua pipeline sesuai dengan beberapa sumber yang dibaca saat mengakses webui dan dengan demikian sejumlah besar build lama memperlambat permintaan

Perbarui Jenkins ke ver. 2.107.1

• Perbarui file perang jenkins
• Nonaktifkan pengaturan keamanan plugin Use browser for metadata download karena tidak memungkinkan untuk memperbarui plugin
• Perbarui plugin ke versi terbaru yang tersedia

EDIT 2018-03-18:

• Menambahkan eksekutor kedua ke semua node yang berjalan di mm

* memprioritaskan semua agen yang berjalan di mr

Master harus jauh lebih responsif sekarang di bawah beban. Bangun semua harus lebih dekat ke 2 jam dengan 4 jam + sebelumnya.

EDIT 2018-03-24:
maaf atas keterlambatannya, minggu sibuk...

• Menambahkan pekerjaan baru ke jenkinsserver (elektra-jenkinsfile) yang akan menjalankan Jenkinsfile yang ditemukan di repo (setelah ada)

EDIT 2018-03-28:

• Redid file unit terowongan, sekarang mem-parsing file lingkungan dan dengan demikian dapat disesuaikan untuk menunjuk ke beberapa target
• Menambahkan server v2 sebagai budak yang mampu menjalankan buruh pelabuhan
  
  
  
  • menambahkan pengguna jenkins di v2
  
  
  • menginstal openjdk-9 di v2
  
  

EDIT 2018-03-29:

• Perbaiki pengaturan ulimit pada jenkins master

Meskipun saya cukup yakin @ingwinlu atau seseorang sudah menggunakan ini: Sepertinya ryzen v2 salah dikonfigurasi:

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

dari 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 tetapi terjadi pada beberapa kesempatan.

Maaf. Itu tidak memiliki deps yang diinstal dan seharusnya hanya bertindak sebagai Host buruh pelabuhan. Saya akan menghapus bendera tambahan.
//EDIT: harus dilakukan. semoga cukup
//EDIT2: Saya juga menonaktifkan test-docker untuk saat ini karena jelas tidak dapat menemukan gambar build yang diperlukan untuk menjalankan tes.

Tapi sialnya cepat jika benar-benar mendapatkan sesuatu yang bisa dibangun
//EDIT3: renabled test-docker untuk hanya berjalan pada node dengan tag docker-prefab dan memberikan tag itu ke ryzen

Sayangnya masalahnya tampaknya lebih besar dari yang diperkirakan semula.

Beberapa pekerjaan memiliki node yang di-hardcode. Beberapa tag sudah usang (stabil pada node jessie). Beberapa pekerjaan tidak memerlukan node yang tepat dan di mana hanya dieksekusi pada yang benar karena dieksekusi di sana sekali sebelumnya dan berhasil dibangun.

Pengenalan node baru (ryzen v2 native) mengacak alokasi sedikit meskipun seharusnya tidak.

Harap harapkan beberapa perilaku tak terduga sampai semuanya berjalan seperti semula.

Catatan perubahan:

• berganti nama menjadi node, <os>-<hostname>-<buildenv>
• dinonaktifkan elektra-multiconfig-gcc47-cmake-options
  itu sebenarnya belum berjalan pada budak gcc47 untuk beberapa waktu sekarang, dengan campuran bangunan gcc49 atau gcc63 tergantung di mana itu dijadwalkan. Jika diaktifkan kembali, mungkin harus masuk ke dockercontainer yang diaktifkan gcc63 di v2
• menandai ulang banyak pekerjaan (mungkin telah melewatkan beberapa di antaranya)
  
  
  
  • elektra-todo membutuhkan stable , tetapi tidak semua node stabil benar-benar menginstal sloccount
  
  
  • banyak lagi kasus serupa
  
  

A7 sepertinya turun

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

Meskipun saya cukup yakin @ingwinlu https://github.com/ingwinlu or
seseorang sudah menggunakan ini: Sepertinya ryzen v2 salah dikonfigurasi:

FATAL: Tidak dapat menerapkan tag jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException: Perintah "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" mengembalikan kode status 128 :
stdout:
stderr:
* Tolong beri tahu saya siapa Anda.

Lari

git config --global user.email " [email protected] "
git config --global user.name "Nama Anda"

untuk menyetel identitas default akun Anda.
Abaikan --global untuk menyetel identitas hanya di repositori ini.

fatal: nama ident kosong (untuk [email protected] ) tidak diperbolehkan

dari
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
tetapi terjadi pada beberapa kesempatan.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377344978 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEOv-ifc-Ns9q0wuscPa3t8AMo15A07iks5tjTTcgaJpZM4DIApm
.

Apakah Anda ingin mengerjakannya? Aku bisa reboot hari ini. Sebagai alternatif admin kami atau saya bisa reboot pada hari Selasa.

Jika tidak terlalu merepotkan. Kalau tidak, saya tidak bisa mengerjakan PR saya selama ini
akhir pekan

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

Apakah Anda ingin mengerjakannya? Aku bisa reboot hari ini. Sebagai alternatif kami
admin atau saya bisa reboot pada hari Selasa.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

Oke, saya me-restart dan juga menonaktifkan C6-State di BIOS/UEFI (diaktifkan). Saya juga menghapus gnome/xorg (saya pikir saya sudah melakukannya?).

Omong-omong. layarnya benar-benar hitam, jadi kami hanya bisa menebak apa penyebabnya.

ini telah muncul di a7 setiap 10 menit atau lebih:

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)

Itu mungkin alasan untuk downtime a7 serta beberapa perilaku build yang aneh di a7 latelty

Bagian valgrind dinonaktifkan di elektra-ini-mergerequests saat dijalankan melalui make run_memcheck

ini telah muncul di a7 setiap 10 menit atau lebih

Ya, kami sudah melihat mereka. Ketika komputer dibeli, seseorang benar-benar memeriksa apakah ECC berfungsi dan tidak ada kesalahan seperti itu yang terjadi saat itu. Apakah frekuensi kesalahan ini tergantung pada beban sistem?

Bagian valgrind yang dinonaktifkan di elektra-ini-mergerequests saat dijalankan melalui make run_memcheck

Terima kasih telah membersihkan ini.

Saya mengalami pengambilan acak (wadah mogok, bangunan berhenti di tengah, terputus, ...) di a7 tanpa log 'nyata' lagi. hanya koreksi memori yang telah disebutkan.

Terima kasih, sepertinya ada yang salah. Dan kami sekarang juga memiliki kesalahan yang tidak dapat diperbaiki:

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

ada pergi a7 lagi.

di bagian depan yang lebih produktif: Saya memasang frontend samudra biru ke jenkins. Pratinjau

ada pergi a7 lagi.

Ini benar-benar membuat frustrasi. Saya me-restart mesin dan menghubungkan kembali agen. Saya akan meminta admin kami untuk mengganti RAM besok, jadi harapkan downtime besok.

di bagian depan yang lebih produktif: Saya memasang frontend samudra biru ke jenkins. Pratinjau

Tampak hebat! Mungkin Anda bisa menunjukkannya kepada kami di pertemuan berikutnya?

Admin kami sudah di akhir pekan. Saya akan mem-boot ulang a7 dan mengatur ulang BIOS/UEFI ke default pabrik. Jika kesalahan berlanjut selama akhir pekan, dia berharap akan menukar RAM.

EDIT: Tidak ada pekerjaan pembangunan yang berjalan, jadi tidak ada pekerjaan pembangunan yang dibatalkan.

EDIT: Semuanya naik lagi. Tidak ada kesalahan Memori sejauh ini.

Terlihat jauh lebih baik. Apakah seseorang terlalu banyak menonton tip teknologi linus dan melakukan overclock server?

Maaf, saya harus menghentikan Jenkins untuk beberapa waktu. Server memuat 20 dan hal-hal yang perlu saya lakukan tidak mungkin lagi (> 1 jam waktu tunggu, lalu saya menyerah dan menghentikan Jenkins).

Apakah mungkin pekerjaan build yang tidak dimulai membutuhkan RAM? (daftar antrian sangat panjang) Jika tidak, pekerjaan pembangunan lokal adalah kandidat terbaik untuk masalah ini. (3 pekerjaan membangun lokal sedang berjalan)

@ingwinlu Idealnya, kami tidak membangun apa pun di server itu. Selanjutnya, dapatkah kita membuat pekerjaan build tergantung pada beban di server. (Jangan memulai pekerjaan di server dengan beban > 5?).

Saya memulai semuanya lagi tetapi saya harap kami menemukan solusi cepat untuk itu.

Saya memompa VERSION dan CMPVERSION di pengaturan sistem Jenkins.

@ingwinlu Akan sangat bagus jika kami memiliki pengaturan ini juga di dalam Jenkinsfile.

@ markus2330 lihat 8de9272051fe903a7df08f0abdf18879701f7ac9 untuk contoh tentang cara mencapai ini di Jenkinsfile

Dihapus make run_memcheck dari target berikut karena mereka gagal sejak beberapa waktu dan akhirnya muncul di sistem build berkat #1882

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

batasi elektra-gcc-configure-debian-stretch untuk dijalankan pada node: stretch && !mr

Perbarui jenkins master ke ver. 2.107.2 + perbarui semua plugin

Saya mencoba menambahkan allowMembersOfWhitelistedOrgsAsAdmin ke semua pekerjaan pembangunan hari ini tetapi sepertinya saya masih tidak dapat memicu pembangunan semua (lihat #1863) dengan benar dan hanya beberapa pekerjaan yang dieksekusi

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

Bisakah seseorang tolong?

• memperbaiki
• menonaktifkan, atau
• (bahkan lebih baik) hapus

elektra-clang-asan tolong 🙏. Saat ini pekerjaan build gagal meskipun semua tes gagal:

• testlib_notifikasi
• testshell_markdown_base64
• testshell_markdown_ini
• testshell_markdown_mini
• testshell_markdown_tcl
• testshell_markdown_xerces
• testshell_markdown_tutorial_validation

bekerja dengan baik di Travis .

Mereka tidak menguji sama seperti (misalnya) mereka menggunakan versi dentang yang berbeda ...

Karena utas ini benar-benar tidak dapat dilacak untuk laporan bug atau diskusi yang lebih panjang, saya akan membuka masalah baru untuk dentang dan dentang-asan segera setelah saya mendapatkannya.

Mereka tidak menguji sama seperti (misalnya) mereka menggunakan versi dentang yang berbeda ...

Saya setuju, sementara Travis menggunakan clang 5.0.0 , versi Dentang pada elektra-clang-asan sudah kuno ( 3.8.1 ). Saya tidak melihat nilai pekerjaan build yang diaktifkan ASAN untuk kompiler lama.

Saya membuat #1919 untuk tes "testlib_notification" yang gagal pada "elektra-clang-asan".

Saya menguji build all dengan semua mr agents dinonaktifkan dan master sangat responsif sementara build all dengan semua mr agents diaktifkan benar-benar menghabiskan waktu beberapa build. Oleh karena itu #1866 pasti akan memberikan peningkatan jika kita dapat menyingkirkan semua agen tuan (-mengi karena tidak dapat ditampung)

Pengujian lebih lanjut menunjukkan bahwa itu hanya pekerjaan pembuatan beranda. Saya menghapusnya dari build all untuk saat ini sehingga hanya dijalankan secara eksplisit.

Ini akan diganti dengan solusi kemas.

v2 online lagi dengan BIOS terbaru.

Harap laporkan kesalahan apa pun di sini (CPU mungkin bermasalah).

a7 tampaknya turun?

Pada 4 Mei 2018 pukul 11:10, markus2330 [email protected] menulis:

v2 online lagi dengan BIOS terbaru.

Harap laporkan kesalahan apa pun di sini (CPU mungkin bermasalah).

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-386545292 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEOv-qhlMoQ78eNfpLpzXEBLTcq0pKT5ks5tvBsXgaJpZM4DIApm
.

a7 aktif lagi dengan BIOS terbaru

a7 turun lagi?

Ya, itu telah jatuh. Itu menunjukkan prompt login tanpa pesan kesalahan dan tidak ada reaksi sama sekali terhadap input apa pun (termasuk sys-req). Hanya hard-reset yang membantu.

Jika Anda tahu apa masalahnya, tolong beri tahu.

sayangnya tidak ada jurnal persisten yang disiapkan di a7 jadi tidak ada log

kapan kita bisa mengharapkan a7 dan v2 tersedia lagi?

Ohh, saya tidak tahu mereka turun. Saya akan meminta admin kami untuk reboot dan jika dia tidak bisa saya akan melakukannya sekitar pukul 17:00.

Sunting: Dia bilang dia akan mengatur ulang mereka sekarang.

Sunting: Mereka berdua bangun lagi.

saya me-reboot a7 dan v2 secara manual hari ini. sepertinya v2 sudah tidak bisa dijangkau lagi. bisa tolong itu benar-benar berjalan?

//EDIT: diselesaikan dengan memperbaiki konfigurasi jaringan di kedua mesin

ternyata a7 udah down lagi.

Oke, saya akan me-reboot dia. Jika tidak, kami tidak akan pernah menyelesaikan rilis ini.

ada indikasi penyebabnya? hanya masalah jaringan atau mesin tidak responsif lagi?

Semuanya harus berdiri dan berjalan sekarang.

Saya baru saja mendapatkannya pada saat yang tepat, ada beberapa log sampai akhirnya benar-benar membeku.

Log adalah:

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

Itu bisa apa saja. dari cpu ryzen yang rusak ke psu yang buruk :(

Pada 12 Mei 2018 pukul 14:33, markus2330 [email protected] menulis:

Semuanya harus berdiri dan berjalan sekarang.

Saya baru saja mendapatkannya pada saat yang tepat, ada beberapa log sampai akhirnya
benar-benar beku.

Log adalah:

INFO: rcu_sched mendeteksi gangguan pada CPU/tugas:
...
rcu_sched kthread kelaparan untuk 7770 sekejap
pengawas: BUG soft lockup - CPU #2 macet selama 22 detik! [gen buruh pelabuhan]
... (banyak pengulangan)
Pengawas NMI: Watchdog mendeteksi LOCKUP keras pada cpu 2

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

Tentang #1993

@ingwinlu Harap nonaktifkan pekerjaan jika saat ini tidak berhasil (atau setidaknya jangan memicu mereka secara default atau dengan "jenkins build all please"). Ini harus memiliki prioritas tinggi bahwa kita tidak gagal pekerjaan di PR di mana sebenarnya semuanya baik-baik saja. (as gagal untuk beberapa waktu bukanlah situasi yang baik)

Jika mereka gagal karena beberapa tindakan Jenkins yang Anda lakukan, memulai kembali pekerjaan akan menyenangkan :heart: Mengatakan demikian di #160 juga tidak apa-apa.

v2 sudah aktif lagi, dengan CPU baru!

Silahkan kirimkan banyak pekerjaan untuk stress-testing :smile:

a7 sepertinya down lagi.

Terima kasih, semuanya naik lagi.

Saya me-restart a7 lagi.

Memiliki sirkuit yang mengatur ulang a7 setiap jam kemungkinan besar akan meningkatkan ketersediaan.

kapan kita bisa berharap untuk melihat a7 kembali online lagi?

a7 kembali online

v2 kembali online

Catu daya v2 akan ditukar dalam waktu sekitar 1 jam.

@ingwinlu dapatkah Anda menonaktifkan agen dan mengaktifkannya lagi setelahnya? (Jika Anda sedang mengerjakannya.)

agen v2 dinonaktifkan untuk saat ini

v2 berjalan lagi. Ini memiliki catu daya baru. Silakan kirimkan banyak pekerjaan untuk menguji mesin.

Saya memperbarui plugin jenkins. Reboot yang dihasilkan memulihkan sebagian node jenkins lama (sebelum diganti namanya) menghasilkan build yang rusak di mana-mana karena repositori git rusak.

Saya membersihkan repositori yang terpengaruh dan membersihkan wadah buruh pelabuhan yang di-cache hanya untuk memastikan.

a7 turun lagi dan karena itu build berbasis buruh pelabuhan tidak tersedia lagi.

Saya juga mengembalikan pembaruan ke xunit karena melanggar batasan keamanan.

Saya me-reboot a7 dan menghubungkan kembali semua agen.

build docker tidak tersedia karena a7 sedang down lagi.

Saya me-reboot server dan menghubungkan kembali agen.

Saya pikir mengganti a7 adalah cara terbaik ke depan, lihat #2020

Saya pikir itu turun lagi, komit terbaru saya mengakibatkan Tidak dapat menghubungi a7-debian-stretch: java.lang.InterruptedException

@e1528532 Terima kasih telah menulisnya di sini! Jika mau, Anda juga dapat memilih di #2020

Saya me-restart a7 dan menghubungkan kembali agen.
Mari kita berharap yang terbaik agar tidak terjadi masalah selama akhir pekan.

a7 turun lagi :cry: Mengejutkan bahwa itu hampir berhasil sepanjang akhir pekan. Mungkin rekor uptime minggu ini. Meski demikian #2020 tidak mendapatkan banyak komentar.

Saya me-restart a7 (bereaksi terhadap sysctl) dan orang lain memulai jenkins. Semuanya berjalan dan berjalan lagi.

a7 baru saja turun lagi.

Terima kasih atas informasinya! Saya me-restart a7 dan menghubungkan kembali agen.

Apakah masuk akal jika kita memiliki agen "debian-jessie-minimal"? Saya pikir Anda dapat menghapusnya dengan aman setelah terintegrasi di Docker. (dan sepertinya sudah)

EDIT:
Di https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log
dan https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
ada peringatan:

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)

kabar buruk. v2 juga turun.

EDIT: tapi sepertinya saya bisa menghubungkannya melalui ssh ....
EDIT2: mengeluarkan reboot pada v2 tetapi sekarang saya tidak dapat lagi terhubung. masih bisa ping dari a7...

EDIT3: sekarang a7 juga turun.

Terima kasih telah melaporkan! Saya me-reboot a7 dan v2. Kita harus mempertimbangkan kembali #2020.

saya pikir v2 turun lagi:

Tidak dapat menghubungi v2-debian-stretch: java.lang.InterruptedException

Dengan v2 semuanya baik-baik saja tetapi a7 turun lagi. Semua agen sekarang online lagi.

v2 tampaknya semi tidak responsif lagi. pingable dari a7 tetapi tidak ada tindakan ssh sama sekali. harus menjadi masalah btrfs dari gejala saja. dapatkah Anda me-reboot semuanya sebelum Anda pulang untuk akhir pekan?

@ingwinlu Terima kasih, @waht dan saya berhasil

ssh hanya berfungsi saat tidak terhubung melalui jembatan.

setelah memulai kembali layanan bridging, koneksi dapat dibuat.

sepertinya terowongan ssh berakhir dalam keadaan aneh yang tidak terdefinisi dan tidak bunuh diri. Tidak yakin mengapa itu tidak bunuh diri (interval serveralive aktif).

Saya juga perlu membersihkan semua ruang kerja secara manual di v2 karena fs rusak dan semua pekerjaan pembangunan gagal.

a7 tampaknya turun. Saya tidak yakin apakah saya dapat mem-boot ulangnya sebelum hari Senin.

Saya memulai ulang a7 dan v2. (v2 karena ada pesan kesalahan pada a7 yang tidak dapat membuat jembatan ssh ke v2. Tetapi juga setelah restart v2 pesan kesalahan yang sama terjadi. Namun demikian, jembatan ssh tampaknya berfungsi. Mungkin beberapa ketergantungan (jaringan?) hilang di skrip boot dari a7?)

Mungkin beberapa ketergantungan (jaringan?) tidak ada dalam skrip bootup a7

Tidak, itu ada.

itu tidak dapat membuat jembatan ssh ke v2

Saya percaya perilaku ini terjadi ketika kernel v2 mulai tidak responsif (dan dengan demikian tidak ada koneksi jaringan masuk yang dapat dibuat). Di masa lalu Anda menyebutkan log yang menunjukkan kesalahan btrfs pada v2.

Saya menyiapkan server build untuk shutdown untuk menggantikan CPU nanti.

a7 dan v2 kembali lagi (a7 dengan CPU baru, v2 dengan sistem file root diperiksa)

sementara itu terus berlanjut di siang hari (dengan buildign yang konsisten) sepertinya a7 baru saja turun lagi.

Ya, saya akan memulai kembali besok pagi.

Kita harus kembali membahas #2020.

Saya me-restart a7. Itu lagi CPU hang.

a7 turun lagi.

Terima kasih, saya memulai kembali. Semua agen kembali online.

Sepertinya beberapa node debian sedang down dan dengan demikian beberapa PRS sudah menunggu lama untuk eksekusi tes dimulai. Apakah itu dimaksudkan?

Sepertinya beberapa node debian sedang down dan dengan demikian beberapa PRS sudah menunggu lama untuk eksekusi tes dimulai. Apakah itu dimaksudkan?

Selama pemutakhiran pada node mm-debian-unstable, mesin menjadi tidak responsif dan kami tidak dapat menghubungkannya sejak itu. Karena pemiliknya tidak menanggapi email kami, itu mungkin akan hilang selamanya.

Meskipun kami telah mem-porting sejumlah besar pekerjaan pembangunan ke sistem baru, yang hilang adalah pekerjaan yang saat ini tergantung dalam antrian.

Saya menonaktifkan pekerjaan yang terpengaruh dan menandainya sebagai diganti + dihapus dari dokumen

@ingwinlu Terima kasih telah mengurus ini!

Membaca tes xdg cukup penting jika seseorang ingin mengerjakan resolver. Saya menambahkannya di posting teratas di sini. Bisakah Anda memperbarui apa yang sudah Anda capai dalam daftar periksa di atas?

Kali ini v2 adalah pemenang yang beruntung.

@ markus2330 saya membersihkan posting teratas.

Terima kasih atas pembersihannya! Saya akan me-reboot v2 (dan mungkin a7, mari kita lihat) besok pagi.

Saya mem-boot ulangnya. Tidak ada reaksi dan tidak ada pesan. Lihat #2020

Silakan reboot a7 dan v2.

Saya me-reboot a7. Saya tidak menemukan masalah dengan v2, haruskah saya me-rebootnya?

i7 sekarang tersedia di 192.168.173.96 bisakah Anda membuat jembatan melalui a7 ke sana?

Anda perlu membuat pengguna ssh-tunnel-a7-v2 di mesin atau membuat akun untuk saya.

Kami menambahkan build slave tambahan i7-debian-stretch yang akan membantu libelektra buildjobs.

v2-docker-buildelektra-stretch (offline) karena tidak ada lagi pekerjaan pembangunan yang dijadwalkan di sana. Ssh-bridge pada a7 yang mengekspos agen juga telah dinonaktifkan.

Halo @ingwinlu ,
seperti yang dibahas dalam pertemuan terakhir, saya akan membutuhkan titik akses.
Bisa tolong kirimkan saya informasinya per email, email saya ada di AUTHORS.md .
Omong-omong. tidak dapat menemukan email Anda di mana pun, mungkin Anda harus menambahkan diri Anda ke file ini.

Server build v2 kami akan offline hingga 31.07 09:00 saat kami menjalankan benchmark di atasnya. Harapkan waktu pembuatan yang lebih lama.

Maaf untuk ketidaknyamanannya.

//EDIT: perpanjangan waktu henti selama 2 jam

Sepertinya ekstensi sekarang juga sudah lewat. Akan lebih baik untuk kembali membangun puasa setelah makan siang (sekitar pukul 13:00). :senyum:

mm-debian-unstable telah ditingkatkan dan kembali online. Apakah ada pekerjaan yang dapat kita aktifkan kembali dan pin ke server?

Sepertinya disk i7 penuh. Pekerjaan saya gagal dengan No space left on device ( Pekerjaan dan Pekerjaan )

Omong-omong, saya sangat suka antarmuka build baru (dockerization & jenkinsfile). Sangat membantu untuk mereproduksi kesalahan build.

Terima kasih telah melaporkan!

Sayangnya mengubah ukuran akan membutuhkan restart (rootfs perlu dibuat lebih kecil sebelum yang lain dapat diperpanjang) dan hanya akan membawa 20G. Saya menghapus folder build Jenkins tetapi ukurannya kecil, jadi kami masih 99%.

Jadi membersihkan _docker akan lebih efektif:
@ingwinlu sepertinya keduanya _docker/overlay2 sangat besar. Tahu mengapa semua barang ini dikumpulkan di sana?

Saya memaksa artefak buruh pelabuhan yang dibersihkan dengan docker system prune -fa . Ini
membersihkan sekitar 190GB ruang yang digunakan dalam gambar buruh pelabuhan.

Pada Senin, 13 Agustus 2018 pukul 07:54, markus2330 [email protected] menulis:

Terima kasih telah melaporkan!

Sayangnya mengubah ukuran akan membutuhkan restart (rootfs perlu dibuat
lebih kecil sebelum yang lain dapat diperpanjang) dan hanya akan membawa 20G. Saya
menghapus folder build Jenkins tetapi ukurannya kecil, jadi kami masih di
99%.

Jadi membersihkan _docker akan lebih efektif:
@ingwinlu https://github.com/ingwinlu sepertinya keduanya _docker/overlay2
sangat besar. Tahu mengapa semua barang ini dikumpulkan di sana?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412415127 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEOv-oK9dSc27dbXOwgSq4xSWa4IXwiUks5uQRSwgaJpZM4DIApm
.

Terima kasih!

Bisakah kita memasukkan ini ke dalam libelektra-harian atau ke dalam cronjob?

Setiap hari melakukan hal serupa tetapi kurang agresif. Harus mengambil yang lain
lihat ketika saya kembali di Wina.

markus2330 [email protected] schrieb am Mo., 13. Agustus 2018, 09:22:

Terima kasih!

Bisakah kita memasukkan ini ke dalam libelektra-harian atau ke dalam cronjob?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRiIC7Mhks5uQSkzgaJpZM4DIApm
.

Seperti yang mungkin Anda perhatikan, server build mati di pagi hari (mungkin di malam hari). Unit catu daya rusak dan sekarang diganti.

Selanjutnya a7 atau v2 mungkin offline untuk benchmark untuk jangka waktu pendek di minggu depan. Anda akan melihat "benchmark" pesan offline jika anton memulai benchmark. Jika komputer tetap offline terlalu lama (misalnya lebih dari satu hari) silahkan hubungi kami. (Maka mungkin lupa untuk beralih ke online lagi.)

Menyelesaikan masalah dengan gambar sisi kami.

testkdb_allplugins dipisahkan pada gambar sid kami selama pengujian debian-unstable-full-clang tetapi hanya ketika dijalankan pada v2. Saya memperbarui gambar secara manual untuk menggunakan paket terbaru yang tersedia dan memasukkannya ke registri kami.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ lulus, tetapi akan mengawasinya.

Masalah ini telah disebutkan di #2216 dan #2215 ( @mpranj @sansecours).

Saya menerapkan akses publik ke registri buruh pelabuhan kami. Lihat di sini untuk beberapa dokumentasi tentang cara mengaksesnya.

Beri tahu saya jika ada yang tidak berfungsi seperti yang diharapkan.

//EDIT sepertinya push tidak berfungsi meskipun login berhasil.
//EDIT2 akses publik dinonaktifkan lagi. https://github.com/moby/moby/issues/18569. mengembalikan fungsionalitas untuk membangun sistem
//EDIT3: repo publik aktif lagi di hub-public.libelektra.org

Anton ingin mengganti mainboard komputer yang hyper-threadingnya dinonaktifkan Selasa atau Rabu depan (bisa pilih). Apakah seseorang membutuhkan buildserver pada salah satu dari dua hari ini?

saya me-restart registri buruh pelabuhan dan menjalankan pembersihan secara manual. mudah-mudahan itu menyelesaikan masalah pembuatan apa pun dengan gambar situs web.

@ingwinlu terima kasih atas pekerjaan pemeliharaannya!

Sayangnya tahap WebUI gagal cukup andal, misalnya 321 atau 320 (gagal lebih awal tetapi juga saat menarik WebUI?).

Saya semakin yakin bahwa pembatalan pekerjaan pada master adalah ide yang buruk. Kami hampir tidak memiliki build pada master yang berhasil karena build dibatalkan atau gagal karena masalah jaringan. Dalam sejarah komit , sulit untuk mengatakan apa yang terjadi karena bagaimanapun mereka hanya ditampilkan sebagai kegagalan.

Sebagai solusinya, saya menonaktifkan tahapan yang tidak dapat diandalkan di c3b59ecef95287ffc33b094b37e03d0ec6b5710f tetapi saya harap kami dapat segera mengaktifkannya lagi!

Haruskah a7-debian-stretch masih offline untuk benchmark? (dimatikan sejak 21 Februari 2019 10:47:56)

Terima kasih telah melaporkan! Sepertinya Anton lupa mengaktifkan kembali. Saya mengaktifkan node lagi dan saya juga menghapus node lama (kecuali mm karena masih berjalan).

Ada downtime server kami di pagi hari. Semuanya berjalan kembali tetapi kami mendapat tawaran bahwa mereka akan menukar perangkat keras. Jadi kemungkinan besar kita akan mengalami downtime lagi sekitar satu jam hari ini.

Server sudah aktif lagi. Sayangnya kami mendapat perangkat keras yang sama. Jika ada yang punya waktu untuk instalasi/setup, kita bisa mengupgrade hardwarenya.

Sepertinya build Jenkins cukup lambat (beberapa jam untuk build penuh). Sejauh yang saya tahu, hanya a7-debian-stretch dan i7-debian yang menjalankan tes, sementara semua node lain menganggur. Apakah ini perilaku yang diharapkan?

Terima kasih telah melaporkan masalah ini!

Tidak, ini bukan perilaku yang diharapkan. Sepertinya v2 sedang down. Saya akan reboot secepatnya.

v2 sekarang harus naik lagi

v2 sedang down dan saya khawatir akan tetap seperti ini sampai hari Senin. Membangun akan sangat lambat sampai saat itu.

v2 lagi dengan mainboard baru

Saya akan meningkatkan semua 3 agen build (i7, v2, a7, dalam urutan itu) ke Buster untuk menghindari #2852

Saya akan mencoba untuk menjaga downtime seminimal mungkin. Pekerjaan build mungkin gagal, silakan mulai ulang (setelah agen aktif kembali).

i7-debian-buster, mantan i7-debian-stretch online lagi

v2 berikutnya

v2-debian-buster dan a7-debian buster juga online lagi

Saya memulai kembali pekerjaan build sebelumnya yang berhasil pada master untuk melihat apakah semuanya berfungsi kembali:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

Selanjutnya, saya menambahkan PR https://github.com/ElektraInitiative/libelektra/pull/2876 untuk mengaktifkan pekerjaan buster build.

v2 sepertinya sedang down (juga koneksi ssh gagal), sayangnya saya tidak di Wina. Saya harap sysadmin kami akan memperbaikinya besok.

a7 sekarang juga turun dan dengan itu i7 (yang terhubung melalui jembatan di atas a7).

Jadi saat ini tidak ada build yang dapat dilakukan. Saya menghubungi administrator.

Semua server aktif kembali. Silakan mulai ulang build dengan mendorong komit baru atau menulis "jenkins build libelektra please" sebagai komentar untuk PR Anda.

Catatan teknis: a7 turun karena "penguncian lunak bug pengawas". Saya mencoba menambahkan "nomodeset nmi_watchdog=0". Mari kita berharap mereka tidak lagi tidak stabil seperti sebelumnya.

a7 (dan juga v2 dan i7 karena mereka terhubung melalui jembatan di atas a7) turun. Saya menghubungi admin kami. Harap hindari untuk memulai pembuatan sekarang, karena hanya akan membuat antrean panjang.

a7 kembali online (sudah kemarin), v2 tidak terpengaruh

Menurut halaman status server build , server:

• a7-debian-buster ,
• i7-debian-buster , dan
• v2-debian-buster

sedang turun. Direktori data Jenkins tampaknya juga cukup penuh. Dan sementara kami melakukannya: Akan sangat bagus, jika kami dapat memutakhirkan Jenkins dan pluginnya. Saya tertarik untuk memperbaiki masalah ini. Ada dua masalah meskipun.

1. Saya tidak memiliki banyak (atau benar-benar) pengalaman mengelola server.
2. Saya mungkin akan membutuhkan akses fisik ke mesin, karena mereka tampaknya sangat tidak stabil.

a7 adalah jembatan ke i7 dan v2, jadi dengan a7 turun kita tidak tahu tentang i7 dan v2.

Aksesnya tidak masalah, saya bisa memberikannya kepada Anda. Tetapi Anda harus menyadari bahwa memutakhirkan Jenkins adalah operasi besar karena biasanya perlu mengkonfigurasi ulang Jenkins (menurut catatan rilis, yang banyak karena kami tidak memutakhirkan sejak beberapa saat) dan untuk memperbaiki Jenkinsfile (sesuai dengan perubahan API dari plugin ). Kirimkan saya email jika Anda ingin akses.

a7 (dan yang lainnya) aktif kembali.

a7 down lagi, saya hubungi admin.

Catatan teknis: a7 turun karena "penguncian lunak bug pengawas".

Pencarian cepat menunjukkan bahwa ini mungkin masalah BIOS. Apakah ada yang memeriksa apakah ada pembaruan BIOS yang tersedia?

a7 adalah jembatan ke i7 dan v2, jadi dengan a7 turun kita tidak tahu tentang i7 dan v2.

Sepertinya itu desain yang buruk. Apakah tidak ada jalan lain untuk itu?

Pencarian cepat menunjukkan bahwa ini mungkin masalah BIOS. Apakah ada yang memeriksa apakah ada pembaruan BIOS yang tersedia?

Kami menginstal BIOS baru, mengganti CPU dan memutakhirkan kernel (lihat pesan di atas). Sistem ini stabil sejak saat itu. Sekarang setelah upgrade ke Debian buster tidak stabil lagi.

Namun demikian, saya bertanya kepada admin apakah ada BIOS baru yang tersedia.

Sepertinya itu desain yang buruk. Apakah tidak ada jalan lain untuk itu?

i7 dan v2 berada dalam jaringan pribadi karena tidak ada cukup alamat IPv4. Saya bertanya kepada admin kami apakah mungkin pengaturan IPv6 dimungkinkan.

Saya bertanya kepada admin kami apakah mungkin pengaturan IPv6 dimungkinkan.

Kami tidak terlalu membutuhkan IPv6, cukup menggunakan server lain yang lebih stabil sebagai jembatan.

Kemungkinan besar, v2 tidak stabil seperti a7 (hanya ada satu crash tetapi ini tidak banyak bicara karena segera ketika a7 mati, dibutuhkan beban v2). Kita bisa menggunakan i7 sebagai jembatan. Tetapi jika v2 dan a7 turun, i7 juga tidak banyak berguna, akan memakan waktu berjam-jam untuk menyelesaikan pekerjaan build. Selanjutnya, i7 tidak memiliki cukup ruang untuk registri buruh pelabuhan.

Jadi perubahan ini akan membutuhkan banyak usaha dengan sedikit keuntungan.

Untuk memperbaiki masalah sebenarnya dari a7 dan v2 jauh lebih menjanjikan.

Selanjutnya, i7 tidak memiliki cukup ruang untuk registri buruh pelabuhan.

Dalam hal ini satu-satunya solusi adalah memperbaiki a7.

Sayangnya a7 down lagi :cry:

Saya mencoba mem-boot dengan kernel lama tetapi ini tidak membantu.

Untuk BIOS ada beberapa versi lain yang tersedia tetapi menurut catatan rilis mereka ada sedikit harapan bahwa mereka akan memperbaiki masalah ini dan tidak ada cara untuk menurunkan versi lagi jika itu akan menjadi lebih buruk ...

BIOS untuk a7 saat ini ditingkatkan. Selanjutnya, kami akan mencoba menggunakan kernel yang lebih baru dari backports.

a7 semoga segera up lagi.

BIOS baru tidak membantu, sekarang a7 mogok dalam beberapa menit.

a7 down lagi, saya hubungi admin. Kernel yang lebih baru dari backport akan dicoba pada reboot berikutnya.

a7 aktif lagi dengan kernel 5.2

Saya pikir itu jatuh lagi ...

Apakah kita masih mendapatkan pesan kesalahan yang sama atau setidaknya ada beberapa perubahan?

Iya a7 down lagi, saya lapor ke admin. Dia akan memberi tahu kami tentang pesan saat memulai ulang.

Apakah seseorang punya ide lain? (Kami sudah memutakhirkan BIOS dan Kernel.)

Beberapa sumber menyarankan masalah dengan driver grafis nouveau dan bahwa kita harus mencoba nouveau.modeset=0 (entah bagaimana ini berbeda dengan nomodeset ). Juga disarankan untuk menonaktifkan "C-states" di BIOS.

Iya a7 down lagi, saya lapor ke admin. Dia akan memberi tahu kami tentang pesan saat memulai ulang.

Apakah seseorang punya ide lain? (Kami sudah memutakhirkan BIOS dan Kernel.)

mungkin nonaktifkan a7 sebagai budak jenkins untuk menentukan apakah itu hanya terjadi ketika beban 'nyata' ada di mesin.

@ingwinlu terima kasih, ide bagus. Saya mengurangi sekarang menjadi satu pekerjaan build a7 (itu 2). Untuk akhir pekan (setelah admin meninggalkan kantor) saya akan menonaktifkan agen sepenuhnya.

@kodebach : terima kasih, informasinya akan saya teruskan ke admin.

Apakah ada timeline kapan a7 akan up lagi?

a7 aktif lagi, dengan hyperthreading dimatikan dan hanya satu pekerjaan build bersamaan.

Kita juga dapat mengurangi beban a7, dengan memindahkan build alpine dan ubuntu-xenial ke Cirrus. Keduanya adalah proses "build and test" yang sederhana. Mereka tidak melakukan sesuatu yang istimewa seperti liputan pelaporan.

Cirrus memungkinkan 8 build Linux secara bersamaan per pengguna . Saat ini build linkchecker adalah satu-satunya build Linux di Cirrus.

Sebenarnya ubuntu-xenial agak berlebihan, karena build Travis kami berjalan di Ubuntu Xenial.

Terima kasih atas tipnya, tetapi kami tidak berencana untuk membongkar build Linux apa pun dari Jenkins. Sebaliknya, @Mistreated akan berupaya meningkatkan infrastruktur Jenkins kami menjadi lebih mutakhir dan berguna (misalnya dengan membuat lebih banyak paket). Keunggulan Jenkins kami adalah:

1. kami memilikinya sepenuhnya di bawah kendali kami
2. kita dapat dengan mudah meningkatkannya (hanya Java+Docker yang diperlukan pada agen build)
3. Jenkinsfile sangat rapi dan (untuk sebagian besar) cukup mudah diperluas

Namun tentu saja, semua orang juga dapat memperluas Cirrus (atau sistem build tambahan lainnya yang ditawarkan secara gratis, lihat #1540).

Itu hanya dimaksudkan sebagai solusi sementara, untuk menangkal penonaktifan hyperthreading dan membatasi hingga 1 pekerjaan bersamaan di a7.

a7 hanya membangun sebagian kecil (sekitar 2/5), jadi pengurangan setengahnya seharusnya hampir tidak terlihat. Atau ada masalah khusus sekarang? (Saat ini, tentu saja, butuh waktu untuk mengejar banyak pekerjaan dari waktu henti.)

a7 hanya membangun sebagian kecil (sekitar 2/5)

2/5 adalah 40%. Saya tidak akan menganggap itu sebagai bagian kecil.

Atau ada masalah khusus sekarang?

Tidak, sebenarnya tampaknya bekerja lebih baik dari sebelumnya.

Maaf, maksud saya sekitar 2/6 (1/6 adalah i7, 3/6 adalah v2). Dan bagian ini tidak dihilangkan tetapi hanya dikurangi.

Tidak, sebenarnya tampaknya bekerja lebih baik dari sebelumnya.

Sempurna!

Kayaknya a7 down lagi .

Terima kasih! Saya melaporkannya.

Di masa depan akan sangat baik jika orang yang mendeteksi pertama dapat langsung melaporkannya ke

herbert di complang.tuwien.ac.at

Cukup dikatakan, bahwa "a7 ist leider nicht erreichbar".

Dan kemudian laporkan juga di sini, agar herbert tidak mendapatkan beberapa email.

Tentunya ada cara untuk membuat server master Jenkins mengirim email seperti itu secara otomatis dan mungkin juga memposting ke masalah GitHub ini. Akan sangat aneh, jika tidak ada plugin Jenkins untuk tugas yang begitu sederhana...

Ya, ada https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin tapi saya tidak yakin itu persis seperti yang kita inginkan. Mungkin juga mengirim email ketika seseorang menghentikan agen dengan sengaja. Dan email pribadi jauh lebih mungkin ditangani oleh admin lebih cepat.

Jika kita mengotomatiskan sesuatu, maka langsung me-reboot PC jika tidak dapat dijangkau (mungkin mereka bahkan memiliki semacam pengawas bawaan?)

a7 telah dimulai ulang dan "kontrol C-State global" dinonaktifkan.

Namun, tidak online sebagai agen build.

Mari kita lihat apakah itu juga macet tanpa beban. v2 dan i7 berfungsi lagi.

Admin (Herbert) tidak tersedia besok, jadi saya meninggalkan a7 sebagai agen build untuk saat ini.

Rencana saya (jika tidak ada protes atau a7 crash sebelumnya) adalah mengaktifkan a7 sebagai build agent besok. Jika a7 crash lagi, Herbert dapat me-restart a7 pada hari Jumat. Apakah ini baik?

Jika antriannya tidak terlalu panjang, saya pikir kita harus menonaktifkan agen build di a7 lebih lama. Kecelakaan terakhir terjadi setelah 3 hari. Jika kami mengaktifkannya besok, kami tidak akan tahu apakah agen pembangunan menyebabkan crash atau tidak, kecuali crash sebelum itu.

Ok, mari kita lihat seperti apa ukuran antriannya.

Saya berharap "kontrol C-State global" akhirnya memperbaiki masalah dan saya pikir kita perlu beban tinggi untuk mengujinya.

Antriannya sangat panjang dan master build semuanya menggantung karena mereka membutuhkan a7 untuk penyebaran situs web.

Jadi saya memulai agen a7 lagi.

Beberapa pekerjaan pembangunan Jenkins baru-baru ini dibatalkan karena tidak ada ruang disk di server pembangunan utama. Saya mengosongkan beberapa ruang dengan menghapus log pekerjaan build lama. Harap perhatikan bahwa saya mungkin juga telah menghapus beberapa file log dari pekerjaan build baru. Dalam beberapa kasus, build Jenkins untuk komit terbaru Anda mungkin gagal dan Anda sekarang hanya melihat beberapa pesan yang berbatasan dengan kesalahan 404. Kalau begitu, tolong saja

• gunakan jenkins build libelektra please dalam komentar di bawah PR untuk memulai ulang build Jenkins, atau
• tulis ulang komit terakhir tanpa perubahan (misalnya menggunakan git commit --amend ) dan lakukan dorongan paksa

. Maaf untuk ketidaknyamanannya.

Terima kasih telah mempertahankannya!

Saya menandai node v2-debian-buster sebagai offline sementara , karena tampaknya tidak berfungsi dengan benar. Untuk informasi lebih lanjut, silakan lihat edisi #2995 (dan edisi #2994).

Terima kasih telah mencari infrastruktur!

v2 kehabisan ruang disk. Saya mengeksekusi docker system prune Total ruang yang direklamasi: 58,37GB

Kemudian saya mem-boot ulang v2 dan membuat agen terhubung lagi.

Saya sekarang mengeksekusi du -h | sort -h untuk menemukan file lain yang akan dihapus.

Saya memulai v2 lagi dengan versi Docker baru. Harap segera laporkan bangunan yang rusak.

Saya menginstal ulang buruh pelabuhan, membersihkan semua konfigurasi, dan menghapus /var/lib/docker. Semoga ini memperbaikinya.

v2 akan disertakan lagi. Harap segera laporkan build yang rusak.

Seperti yang disarankan di sini, saya sekarang mengeksekusi

ethtool -K enp3s0 sg off # on v2
ethtool -K enp0s25 sg off # on i7
ethtool -K enp37s0 sg off # on a7 (internal network interface)

dan saya juga me-restart i7 (ada banyak antarmuka jaringan buruh pelabuhan, mereka hilang sekarang)

docker-ce sekarang ada di mana-mana 5:19.03.1~3-0~debian-buster

Harap segera laporkan bangunan yang rusak.

Sepertinya build master gagal lagi , karena masalah koneksi ke v2-debian-buster (lihat juga masalah #2995).

Saya meminta admin kami untuk melihat peralihan antara a7/v2/i7. Saya menonaktifkan v2 dan i7 untuk saat ini.

Saya memulai kembali libelektra/master dan libelektra-harian.

Kami mengubah port untuk semua 3 PC.

Kemudian saya menghapus jenkins homedir di v2/i7 dan memulai kembali agen v2/i7.

Sepertinya tidak ada lagi ruang yang tersedia di v2-debian-buster :

Status keluar ApplyLayer 1 stdout: stderr: tulis /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o: tidak ada ruang tersisa di perangkat

.

Terima kasih telah melaporkan, saya membuat (lebih) lebih banyak ruang di v2.

Hapus pekerjaan selesai:

Ukuran Sistem File yang Digunakan Tersedia Penggunaan% Dipasang di
/dev/sda3 417G 227G 164G 58% /

buildserver tidak aktif karena migrasi (sehingga kami mendapatkan status yang konsisten dalam cadangan buildserver baru)

https://build.libelektra.org/jenkins/ mulai lagi

Beban pada server build adalah 200 karena kesalahan kernel selama pencadangan, server tidak bereaksi lagi dan perlu diatur ulang.

Pesan log adalah (contoh):

[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]

Semoga kita bisa segera hijrah di awal minggu depan ( @Dianiaya ?)

Server saat ini melakukan sinkronisasi ulang serangan, jadi diperkirakan akan sangat lambat.

Pembuatan Jenkins tidak dilakukan lagi, lihat #3035

Jenkins sekarang mulai lagi. Harap ulangi pekerjaan pembuatan Jenkins.

Sepertinya v2-debian-buster sedang offline:

Membuka koneksi SSH ke a7.complang.tuwien.ac.at:22221.
Koneksi ditolak (Koneksi ditolak)

.

Terima kasih, saya menghubungi admin kami tetapi saya khawatir dia sudah keluar dari kantor.

Herbert sudah me-restart v2 kemarin. Dia menonaktifkan "multithreading simultan".

Jika server (v2, i7, a7) crash lagi, silakan juga langsung hubungi admin kami melalui "herbert di complang.tuwien.ac.at". Harap laporkan juga di sini, untuk menghindari banyak email.

Saya pikir ada yang salah dengan repositori Git untuk cabang master pada 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

. Saya sudah memulai ulang build tiga kali, tetapi Jenkins selalu gagal dengan kesalahan yang sama.

Sayangnya v2 memiliki btrf yang terkadang tampaknya merusak file. Masalah serupa yang sudah kami alami dengan docker pull gagal. Dalam kasus saat ini, file 0bc3ca6fcbc610abd845aeff5f666938d24117 tampaknya rusak. Saat menjalankan md5sum pada kemunculan file ini, saya mendapatkan:

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

Saya sekarang menghapus seluruh direktori untuk master dan memulai kembali build. Lihat juga #3054

Karena saya sekarang tidak tersedia selama beberapa hari, silakan hubungi "herbert di complang.tuwien.ac.at" untuk masalah terkait a7/i7/v2 yang tidak dapat dijangkau. @Mitreated akan bertanggung jawab atas segala sesuatu yang tidak terkait dengan me-reboot server. (Semoga kami akan segera mendapatkan agen build baru.)

Harap juga selalu laporkan di sini, untuk menghindari banyak email dan agar setiap orang memiliki gambaran yang baik tentang apa yang sedang terjadi.

Apakah server build saat ini mengalami malfungsi?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

Apakah server build saat ini mengalami malfungsi?

Sepertinya server build Jenkins utama tidak dapat terhubung i7 . Saya menandai node sebagai offline sementara.

Build gagal pada kasus arbitrer:
Di sini terputus tanpa alasan apa pun
Di sini kasus uji gagal yang tidak terkait dengan PR saya (saya baru saja menambahkan keputusan desain tanpa menyentuh kode apa pun)

Di sini terputus tanpa alasan apa pun

Saya mendapat kode interupsi yang sama 143 untuk dua PR dan belum bisa menjelaskannya. Saya memulai kembali build dan berharap itu berfungsi sekarang.

Di sini kasus uji gagal yang tidak terkait dengan PR saya

Ini harus diperbaiki berkat @sanssecours dengan #3103. Silakan rebase untuk menguasai.

Node Jenkins baru hetzner-jenkins1 tampaknya tidak berfungsi dengan benar . Saya menandai node sebagai offline sementara.

Saya memutakhirkan buruh pelabuhan di i7 dan me-restart mesin. Saya harap ini memperbaiki masalah. Agen sudah online lagi. Silakan laporkan masalah di sini (dan/atau nonaktifkan agen).

Saat ini pekerjaan #3065 sedang berjalan di i7.

@ Dianiaya, bisakah Anda men-debug hetzner-jenkins1?

Apakah ada kemungkinan untuk dengan mudah mematikan pemeriksaan tautan untuk beberapa waktu?

Ini telah terjadi sepanjang hari:

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

PR lain (terakhir #3115, #3113) juga terpengaruh. Menurut tautan downforeveryoneorjustme benar-benar tidak tersedia.

PEMBARUAN: Situs web masih offline. Saya membuat PR untuk #3117 ini.

Apakah ada kemungkinan untuk dengan mudah mematikan pemeriksaan tautan untuk beberapa waktu?

Anda dapat mematikan tautan individual dengan menambahkannya ke tes/linkchecker.whitelist (seperti yang sudah Anda ketahui)

Saya tidak dapat menjalankan kembali build yang gagal dari Cirrus. Lihat https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

Tombol tidak melakukan apa-apa. Apakah ada trik sulap untuk membuatnya bekerja?

edit: entah seseorang mengubah sesuatu atau percobaan ke-x akhirnya berhasil. Pembangunan berjalan lagi! :)

Sepertinya agen build a7-debian-buster tidak dapat diluncurkan kembali:

…
[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

.

edit: entah seseorang mengubah sesuatu atau percobaan ke-x akhirnya berhasil. Pembangunan berjalan lagi! :)

Setelah saya melihat komentar Anda, saya juga menekan tombol "Restart Gagal Membangun Pekerjaan". Sejauh yang saya tahu menekan tombol memang me-restart pekerjaan build yang gagal.

Setelah saya melihat komentar Anda, saya juga menekan tombol "Restart Gagal Membangun Pekerjaan". Sejauh yang saya tahu menekan tombol memang me-restart pekerjaan build yang gagal.

Itu tidak berhasil untuk saya, saya akan memberikan beberapa gif lain kali!

Saya akan me-restart server build dan node-nya. Pekerjaan build #3121 dan #3099 perlu dimulai ulang karena mereka memiliki pekerjaan pada agen mati.

Itu tidak berhasil untuk saya, saya akan memberikan beberapa gif lain kali!

Anda tidak perlu memberikan GIF, karena saya sudah percaya Anda 😊.

Sepertinya jenkins memiliki masalah untuk dihentikan, saya menunggu sebentar sebelum saya secara paksa membunuh semua proses Java.

Saya juga memutakhirkan buruh pelabuhan di semua agen (di i7 sudah ditingkatkan).

Jenkins naik lagi dengan interval detak jantung seperti yang disarankan di #2984. Semua node terhubung.

Silakan mulai ulang semua pekerjaan sesuai kebutuhan dan laporkan masalah apa pun di sini.

v2 sedang down, saya meminta admin kami untuk me-restart.

Saya mengaktifkan v2 lagi, karena tampaknya sudah aktif dan backlog build kami berukuran memadai.

Apakah ada masalah dengan build lagi ( hetzner-jenkins1 )?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

Apakah ada masalah dengan build lagi ( hetzner-jenkins1 )?

Ya . Saya menonaktifkan node.

Itu hanya kuota Disk yang terlampaui, saya tidak ingin berlebihan dengan memori. Aku membersihkannya sekarang. Ini naik lagi.

Node diperbarui.

Saya meningkatkan hetzner-jenkins1 menjadi 4 build paralel. Ini hanya tindakan sementara selama tidak ada lagi yang berjalan di sana.

Saya sementara mengurangi jumlah pelaksana pada hetzner-jenkins1 dari 4 menjadi 2, karena testsuite habis. Saya pikir ini terjadi ketika terlalu banyak pekerjaan yang dikompilasi saat tes sedang berjalan. Kami mungkin perlu membatasi sumber daya yang tersedia untuk satu wadah agar tidak terlalu mengganggu pekerjaan lain.

Jangan ragu untuk memperbaikinya jika menurut Anda ini adalah pendekatan yang salah.

EDIT: turun menjadi 1 karena tes masih kehabisan waktu dan terus-menerus membangun kembali menghabiskan lebih banyak sumber daya.

@mpranj Terima kasih telah memperbaikinya!

@dianiaya apakah Anda mungkin hanya menetapkan satu CPU atau serupa? Bisakah Anda menetapkan lebih banyak dan mengubah jumlah pelaksana lebih tinggi? Perangkat keras harus lebih kuat seperti v2.

Saya menonaktifkan i7-debian-buster karena tidak ada ruang disk yang tersisa yang menyebabkan semua build gagal. Jika seseorang memiliki akses, harap bersihkan sesuatu dan aktifkan kembali.

@mpranj terima kasih telah menonaktifkan!

Maaf, tempat saya saat ini ssh diblokir (beberapa firewall aplikasi, juga ssh pada port lain tidak berfungsi). Jadi saya tidak dapat memberikan akses atau melakukan pembersihan apa pun sekarang.

Karena i7 adalah agen terlemah, itu mungkin bukan masalah besar.

@Dianiaya apakah Anda mungkin hanya menetapkan satu CPU atau serupa? Bisakah Anda menetapkan lebih banyak dan mengubah jumlah pelaksana lebih tinggi? Perangkat keras harus lebih kuat seperti v2.

Saya tidak tahu seberapa kuat v2.
Saat ini jenkins1 menggunakan 4 CPU dengan 8 memori dan 16 swap. Saya dapat meningkatkannya dengan mudah, saya hanya tidak tahu sampai titik mana Anda ingin saya meningkatkannya.

Catatan untuk keputusan perangkat keras di masa mendatang: phoronix tampaknya melakukan tes kompilasi dalam artikel CPU mereka (mis. Ryzen 7 3700X, tes Ryzen 9 3900X, menuju akhir artikel ).

Sepertinya hetzner baru-baru ini menambahkan AMD Ryzen 7 3700X ke server berbasis AMD mereka.

Saya tidak tahu seberapa kuat v2.

@ingwinlu menulis tentang ini dalam tesisnya (dapat ditemukan di abgaben repo lukas_winkler)

Saat ini jenkins1 menggunakan 4 CPU dengan 8 memori dan 16 swap. Saya dapat meningkatkannya dengan mudah, saya hanya tidak tahu sampai titik mana Anda ingin saya meningkatkannya.

Selama kami tidak menjalankan apa pun di server, Anda dapat mengalokasikan semua sumber daya. Nanti kita masih bisa turun (ketika kita memindahkan Jenkins).

Saya memperbarui file hetzner-jenkins1.
Kesalahan dengan frontend yang kehabisan memori telah diperbaiki.
Sekarang menjalankan 2 build paralel.

Sepertinya tidak ada ruang tersisa di v2-debian-buster :

validation.cpp:69:1: fatal error: error writing to /tmp/cccJFleY.s: No space left on device

.

Terima kasih, saya menandainya secara offline juga, sampai seseorang memiliki akses untuk membersihkannya.

hetzner-jenkins1 baru saja gagal 3 PR saya karena kuota disk terlampaui. Berikut ini pada output:

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

Ditandai hetzner-jenkins1 sebagai offline karena kuota disk terlampaui.

Saya membersihkan i7 dan v2 (dengan menghapus /home/jenkins/workspace/* dan dengan menjalankan docker system prune ). Sekarang kita punya:

• i7: /dev/mapper/i7--vg-home 199G 152G 37G 81% /home
• v2: /dev/sda3 417G 255G 147G 64% /

Kemudian saya me-restart agen.

@Dianiaya dapatkah Anda memperbaiki #3160 sehingga ini tidak terulang kembali begitu cepat. Harap perbaiki juga hetzner-jenkins1. Ada banyak sumber daya di mesin ini, benar-benar tidak perlu mencapai batas sumber daya setiap hari.

Saya tidak tahu apakah ada cara yang bagus untuk mengubah ukuran disk. Itu sebabnya saya tidak memberikan simpul semuanya sekaligus .. hetzner aktif lagi.

v2 lagi-lagi kehabisan ruang, saya membersihkan: /dev/sda3 417G 315G 102G 76% /

@Dianiaya https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log tidak memulai

Saya pikir sistem build saat ini benar-benar macet, PR tidak sedang dibangun.

Terima kasih telah melaporkan, saya akan memulai ulang Jenkins dan membersihkan beberapa file karena disk sudah penuh.

@Dianiaya https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log tidak memulai

Agen berhasil terhubung dan online

Saya menganggap semuanya baik-baik saja sekarang dengan hetnzer-jenkins1?

Terima kasih banyak! Sepertinya Jenkins masih belum bereaksi terhadap build. v2 dan i7 sekarang keduanya gagal dengan: java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave .

Jenkins sudah aktif lagi, silakan mulai ulang pekerjaannya.

java.io.IOException: Tidak dapat menyalin slave.jar ke '/ home/jenkins' di slave.

tetap (juga keluar dari ruang)

@Dianiaya tolong perbaiki jenkins-daily karena ini membuat tugas pembersihan yang sekarang harus kita lakukan secara manual!

@Dianiaya "jenkins build libelektra please" masih rusak, apakah ini terkait dengan perubahan webhooks?

Mungkin coba hari ini untuk mengubah ke Jenkins baru tetapi jika Anda tidak dapat melakukannya, harap buat instance lama berfungsi lagi!

Saya memicu pemindaian repositori, sekarang "jenkins build libelektra please" tampaknya berfungsi kembali.

Sepertinya disk penuh untuk v2-debian-buster

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

Sayangnya. Saya menandai v2 sebagai offline sampai diselesaikan.

Terima kasih telah melaporkan!

@mpranj saya memberi Anda akses, bisakah Anda mencoba membersihkannya?

Terima kasih! Tampak bagi saya bahwa ada banyak sumber daya yang terbuang oleh gambar-gambar lama buruh pelabuhan yang tergeletak di sekitar. Selain itu, tampaknya btrfs + buruh pelabuhan bermasalah. Docker membuat subvolume btrfs untuk setiap wadah dan tidak membersihkannya dengan benar setelahnya. Perintah docker system prune -f juga tidak mengosongkan ruang.

Saya menurunkan v2 dan a7 untuk pemeliharaan guna membebaskan sumber daya dan menyeimbangkan btrf.

login buruh pelabuhan gagal

Membangun tidak dapat menarik gambar buruh pelabuhan. Sesuatu terjadi dengan hub buruh pelabuhan?

Ya, maaf, dengan a7 Saya juga menurunkan hub buruh pelabuhan. Saya akan memposting pesan di sini ketika sudah aktif lagi.

a7 termasuk docker hub sudah aktif kembali. Saya meninggalkan v2 offline karena tidak bisa masuk ke hub untuk menarik gambar?!? Saya tidak tahu apa yang salah di sana, saya tidak mengubah kredensial apa pun dan node lain dapat masuk. Ada ide?

Btrfs masih menyeimbangkan di latar belakang, a7 mungkin lebih lambat selama satu jam atau lebih.

@mpranj terima kasih telah memperbaiki ini! Perintah mana yang diperlukan untuk penyeimbangan ulang btrf?

Sayangnya, saya tidak tahu kredensialnya, saya harap @ingwinlu dapat membantu kami.

Perintah yang saya gunakan untuk menyeimbangkan kembali adalah:

Perbaiki bug yang mungkin terjadi dengan btrfs:

btrfs balance start -dusage=0 -musage=0 /mountpoint

Re-balance fs banget, ini butuh waktu lama. Parameter penggunaan dapat/harus disetel, inilah yang berfungsi hari ini:

btrfs balance start -dusage=80 /

Kredensial dapat diubah dengan mudah, tetapi kita harus masuk ke semua agen jenkins yang terhubung ke hub buruh pelabuhan lagi dengan kredensial baru.

Masalah yang lebih besar adalah bahwa beberapa wadah buruh pelabuhan masih berjalan dan pemangkasan sistem buruh pelabuhan tidak berbuat banyak. Oleh karena itu saya menurunkan agen dan membebaskan semuanya saat sedang turun. Ada BANYAK kontainer yang tergeletak begitu saja.

Ya, sayangnya wadahnya cepat dibuat ulang. Saya harap @Mistreated dapat segera memperbaiki pekerjaan libelektra-harian (dieksekusi docker system prune ).

Saya juga melakukan beberapa forensik digital yang cukup terlibat dan mencuri kredensial hub. :tertawa:

v2 aktif dan berjalan kembali.

Terima kasih banyak! :100: Kirimkan kredensialnya kepada kami.

Terkirim. Btw saya pikir a7 mungkin lambat hanya karena kecepatan disk yang buruk, tetapi ada baiknya ia memiliki cukup ruang untuk hub buruh pelabuhan. Sepertinya sebagian besar waktu CPU tidak melakukan apa-apa di sana.

Pikiran lain: mungkin kita bisa melakukan pekerjaan pembersihan kritis tambahan per cronjob untuk menghindari situasi seperti yang kita alami sekarang.

Silakan kirim kredensial kepada kami.

@mpranj Saya pikir saya berada di grup "kita" ini. Saya tidak di beberapa CC atau sesuatu seperti itu?

@Dianiaya maaf, saya mengirimnya ke markus dan tidak memiliki email Anda. Pada a7 Anda akan menemukan CREDENTIALS.txt di homedir Anda.

Saya perlu hetzner-jenkins1 Node untuk menguji server jenkins baru. Saya akan mematikannya di server lama sampai besok pagi.

Anda dapat dengan mudah membuat hetzner-jenkins2 kedua untuk pengujian. Jika hanya untuk malam ini, seharusnya tidak apa-apa.

Pikiran lain: mungkin kita bisa melakukan pekerjaan pembersihan kritis tambahan per cronjob untuk menghindari situasi seperti yang kita alami sekarang.

libelektra-daily melakukan pekerjaan pembersihan ini tetapi sekarang gagal: #3160. Jika Anda memiliki ide untuk meningkatkan pekerjaan ini, beri tahu kami.

Saya pikir saya berada di kelompok "kita" ini. Saya tidak di beberapa CC atau sesuatu seperti itu?

Ya, maaf saya lupa memberi tahu mpranj bahwa "kami" mengacu pada Anda.

Saya harap tidak apa-apa bahwa saya menyimpan hetzner-jenkins1 untuk sementara waktu, semua build bagus sekarang, saya pikir saya dapat membuat server berjalan penuh malam ini.

v2 tidak dapat dijangkau, saya menghubungi admin.

Saya harap tidak apa-apa saya menyimpan hetzner-jenkins1 untuk sementara waktu, semua build bagus sekarang saya pikir saya bisa membuat server berjalan penuh malam ini.

Ini akan sangat bagus!

v2 tidak dapat dijangkau, saya menghubungi admin.

Terima kasih, tetapi saya khawatir dia tidak akan merespons sebelum hari Senin.

v2 mendapat kernel baru (baru saja macet).

i7 juga akan dimulai ulang.

Ketiga server (v2, a7, i7) sekarang memiliki "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 "

Mereka aktif dan online, silakan mulai ulang pekerjaan jika diperlukan.

Hanya sebuah catatan:
Saya memindai repo lagi dengan server baru. Ini bisa membuat beberapa kesalahan pada yang lama..

Sepertinya master [1] juga dibangun di server baru. Itu tidak berhasil. Saat mengklik status, halaman login muncul [2]. Harap konfigurasikan ulang Jenkins agar semuanya dapat dilihat tanpa harus masuk.

Semoga kita bisa segera beralih ke Jenkins baru. Melihat kesalahan dari dua Jenkins yang berbeda tidak membuat situasi lebih mudah :wink:

[1] https://github.com/ElektraInitiative/libelektra/commits/master#
[2] http://95.217.75.163 :8080/login?from=%2Fjob%2Flibelektra%2Fjob%2Fmaster%2F1%2Fdisplay%2Fredirect

@ markus2330 dapatkah a7 / v2 di-boot ulang dari jarak jauh setelah peningkatan atau apakah ada beberapa jebakan?

Biasanya berhasil tapi jika tidak mendesak lebih baik menunggu sampai admin ada. Saya bisa reboot pada hari Selasa jika ini baik-baik saja untuk Anda?

Terima kasih! Tidak ada yang mendesak, hanya pertanyaan umum. Itu muncul karena Debian 10.2 baru saja dirilis. Saya akan menunggu sebentar dengan peningkatan.

Anda dapat melakukan peningkatan (hanya tanpa reboot). Kemudian, jika terjadi crash, kernel 10.2 kita sudah ada ketika admin akan menekan tombol reset :wink:

@mpranj dapatkah Anda menambahkan cronjob yang menghapus snapshot lama? Atau apakah ini tidak mungkin tanpa menghentikan buruh pelabuhan?

https://docs.docker.com/storage/storagedriver/btrfs-driver/ merekomendasikan untuk juga menyeimbangkan kembali btrnfs dalam cronjob.

bisakah Anda menambahkan cronjob yang menghapus snapshot lama? Atau apakah ini tidak mungkin tanpa menghentikan buruh pelabuhan?

Saya dapat menambahkan cronjob tanpa menghentikan semua wadah buruh pelabuhan. Ini mungkin tidak membersihkan semuanya, tetapi kita bisa mencobanya. Seperti yang saya katakan, terkadang kontainer tetap berjalan selamanya/sampai mesin mogok. Pembersihan lengkap mengharuskan kami untuk menonaktifkan sementara agen build, lalu kami dapat menghentikan paksa semua container.

Saya juga dapat menambahkan rebalance sebagai cronjob.

Terima kasih, mari kita coba.

Guru kehabisan ingatan. Saya ingin menjalankan Scan Repository pada Jenkins lama karena a7 dan i7 mendapatkan kesalahan berikut saat menarik gambar buruh pelabuhan:

login buruh pelabuhan gagal

Saya menjalankan v2 dan hetzner-jenkins1 di server baru sekarang.

Guru kehabisan ingatan.

Terima kasih telah melaporkan. Saya menghapus beberapa data cakupan lama dan mengaktifkan kembali master node. Untuk semua orang dengan permintaan tarik terbuka: Silakan mulai ulang build Jenkins Anda dengan jenkins build libelektra please . Maaf untuk ketidaknyamanannya.

Di #3234 @raphi011 disarankan:

imo ini sangat mendesak, kerapuhan dan kelambatan tes membuat sulit jika bukan tidak mungkin untuk melakukan perubahan apa pun jika Anda harus menunggu selama ini untuk memverifikasinya.

Saya setuju ini sangat mendesak tetapi @Mitreated sudah melakukan apa yang dia bisa.

Jadi mungkin kita bisa menggunakan server build lebih hemat dan build hanya jika kita benar-benar berpikir PR akan segera digabungkan. Build yang tidak perlu harus dibatalkan.

Atau bagaimana dengan (sementara) menghentikan pembuatan PR otomatis saat mendorong perubahan (jadi pembangunan hanya dimulai dengan jenkins build libelektra please )? @Dianiaya apakah Anda tahu cara mengkonfigurasi ulang Jenkins untuk melakukannya (saya tidak menemukan opsi)?

Saya juga merasa bahwa jenkins build libelektra please tidak berfungsi saat ini, setidaknya tidak berfungsi untuk build ini: https://github.com/ElektraInitiative/libelektra/pull/3073 saya harus mendorong komit kosong untuk memulai pipa.

Pembersihan cronjob diimplementasikan dan kernel backport ditingkatkan pada a7 dan v2. Ada cukup changelog untuk kernel, itu akan aktif pada reboot berikutnya.

Terima kasih banyak! Apakah kernel backport "lama" masih terpasang sehingga kita memiliki cadangan jika tidak bisa boot?

Ya, itu dapat dihapus setelah berhasil boot ke kernel baru.

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

Saya menonaktifkan i7 untuk pembersihan manual, peningkatan kernel dan buruh pelabuhan. Seseorang mengaktifkan i7 saat saya sedang mengerjakannya. Semuanya berjalan dan berjalan lagi.

@Piankero saya

Saya juga merasa bahwa jenkins build libelektra please tidak berfungsi saat ini, setidaknya tidak berfungsi untuk build ini: #3073 saya harus mendorong komit kosong untuk memulai pipeline.

bekerja sekarang

@Dianiaya apakah Anda tahu cara mengkonfigurasi ulang Jenkins untuk melakukannya (saya tidak menemukan opsi)?

Saya menambahkan yang berikut ini ke Konfigurasi Jenkins:

Menekan pemicu SCM otomatis

Catatan untuk semua orang: Penggunaan "jenkins build libelektra please" sekarang wajib, membangun pekerjaan tidak dimulai dengan hanya mendorong. Kami akan menginformasikan di sini, ketika kami mengembalikan pengaturan ini.

@Dianiaya terima kasih! Mari kita lihat apakah ini cukup. Saya harap push to master masih memicu master build?

Namun, memiliki simpul hetzner akan sangat bagus. Apakah ada masalah jika node digunakan oleh dua server build secara bersamaan? Atau jika ada masalah: bukankah sangat mudah untuk mengkloning CT?

@Dianiaya terima kasih! Mari kita lihat apakah ini cukup. Saya harap push to master masih memicu master build?

cabang master sekarang merupakan pengecualian dari aturan berikut:

Menekan pemicu SCM otomatis

Adapun

Namun, memiliki simpul hetzner akan sangat bagus. Apakah ada masalah jika node digunakan oleh dua server build secara bersamaan? Atau jika ada masalah: bukankah sangat mudah untuk mengkloning CT?

Saya menambahkan CT baru (hetzner-jenkinsNode3).

tidak dapat mengkloning repo: https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

mungkin ini ada hubungannya dengan node baru? (tebakan asal)

mungkin ini ada hubungannya dengan node baru? (tebakan asal)

kesalahan ini ada di a7

kesalahan ini ada di a7

soooo.. coba lagi?

soooo.. coba lagi?

ya, saya tidak berpikir itu akan terjadi lagi..

Saya akan menjalankannya kembali untuk Anda.

@Dianiaya Saya pikir kita dapat memulai pembuatan otomatis lagi. Tapi tolong lihat #3160 dulu.

tahu mengapa ini akan gagal?

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

tahu mengapa ini akan gagal?

Kedengarannya seperti itu adalah masalah sementara, URL saat ini dapat diakses dari agen build.

Dalam jangka panjang, akan sangat bagus untuk mengatur dependensi semacam itu di gambar buruh pelabuhan, untuk menghindari mengunduhnya untuk setiap build berulang kali. Itu juga harus mencegah kegagalan build karena paket yang tidak tersedia untuk sementara seperti yang Anda sebutkan di atas.

Kalau begitu.. jenkins build libelektra please yang ketiga

Ya, kami memiliki semua dependensi langsung di gambar buruh pelabuhan karena alasan ini. Saya membuat #3251

Saya mengambil v2 dan a7 offline untuk reboot.

@markus2330 jika Anda mendapat kesempatan, aktifkan hyperthreading di a7 .

v2 naik lagi, di a7 masih ada buildjob.

Saya mengambil node dan menambahkannya ke server baru. Aku akan membiarkannya berjalan di malam hari. Besok saya akan mengembalikan node jika ada kesalahan lebih lanjut di server Jenkins baru.

hetzner-jenkinsNode3 akan tetap berjalan di Jenkins lama.

Besok saya akan mengembalikan node jika ada kesalahan lebih lanjut di server Jenkins baru.

Kesalahan build kecil bukan alasan untuk beralih kembali. Pada titik tertentu kita perlu memperbaiki kesalahan, bolak-balik sangat memakan waktu.

Apa yang mungkin menjadi penghalang pertunjukan, bagaimanapun, adalah bahwa server baru tidak dapat dijangkau. (Juga tidak
http://95.217.75.163:8066 atau ssh). Saya menekan tombol power, mari kita lihat apakah mesin restart. Namun, kita harus menyelidiki apa masalahnya.

http://95.217.75.163 :8066

Jika ada waktu, silakan aktifkan TLS menggunakan letsencrypt, agar kami tidak membocorkan kredensial dan mengekspos diri kami ke berbagai masalah lain?

Terima kasih atas masukannya! Saya menyarankan kita melakukan ini segera ketika kita beralih build.libelektra.org. Jika tidak, kita memiliki upaya ganda.

Apakah kesalahan ini diketahui? Caught the following exception: null

Sepertinya pemeriksaan pemformatan gagal dan build lainnya dihentikan.

kamu benar. sungguh pesan kesalahan yang jelek :P

@Dianiaya dapatkah Anda mengaktifkan kembali bahwa PR dibuat secara otomatis? Karena banyaknya agen, server sekarang kebanyakan tidur.

@Dianiaya dapatkah Anda mengaktifkan kembali bahwa PR dibuat secara otomatis? Karena banyaknya agen, server sekarang kebanyakan tidur.

Selesai.

Saya akan meminjam hetzner-jenkins1 dan v2 lagi untuk server baru.

Anda tidak perlu mengembalikannya, saya harap kita bisa melakukan peralihan hari ini.

Tip: ketika melakukan switch semacam ini, ada baiknya untuk mengurangi TTL entri DNS ke sesuatu yang sangat rendah (misalnya 60 daripada saat ini 21599 untuk build.libelektra.org). Setelah perubahan disebarkan, sebaiknya kita mengganti entri DNS dalam satu menit, bukan berjam-jam. Jika sudah terlambat, ini dapat membantu menghapus cache DNS dari google dan opendns, tetapi beberapa orang pasti akan melihat sumber daya lama hingga entri yang di-cache kedaluwarsa secara global.

EDIT: setelah perubahan, TTL jelas harus dikembalikan ke nilai waras untuk mengurangi beban pada DNS.

Meskipun sekarang mungkin sudah terlambat, saya mengganti $TTL 3600 (jika kami membutuhkan beberapa perubahan hingga semuanya berfungsi).

www-new dan build-new sudah ada menunjuk ke server baru.

Saya sekarang beralih doc.libelektra.org. @Mitreated akan memperbaiki penerbitan. Saya akan melihat ke www-new.libelektra.org

https://build-new.libelektra.org/ dan https://www-new.libelektra.org/home seharusnya berfungsi sekarang.

Saya akan mengubah semua entri DNS sekarang.

Semua entri DNS diubah.

Sayangnya, certbot gagal karena tampaknya berbicara dengan server lama tetapi ini tampaknya hanya memengaruhi unduhan dan komunitas (URL yang lebih jarang digunakan).

Jadi mudah-mudahan, selama/setelah akhir pekan semua orang melihat nama DNS yang diperbarui.

@Dianiaya tolong perbarui penerbitan semua artefak: juga untuk situs web. Harap buat PR untuk memastikan semuanya berfungsi dengan baik.

Server build lama sekarang dimatikan.

Saya perlu me-restart server baru (kernel baru dan jembatan jaringan ditambahkan).

Server sudah aktif kembali dengan Linux pve 5.0.21-5-pve.

Saya menjadwalkan pemindaian ulang semua PR.

server offline karena kesalahan konfigurasi/bug di pve (/etc/network/interfaces telah dihapus oleh GUI?).

Bug adalah penggantian nama perangkat jaringan (yang disebabkan oleh tindakan saya di GUI) mengarah ke 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

Server harus aktif dan berjalan kembali.

Masalah sebelumnya tetap ada, meskipun (frasa tidak berfungsi #3268)

@Mitreated master juga sepertinya tidak membangun secara otomatis lagi, saya memicunya secara manual sekarang.

Saya mengumpulkan kesalahan mendesak di #3268. Akan lebih baik jika Anda juga dapat menguji apakah semuanya berfungsi seperti yang dijelaskan di doc/BUILDSERVER.md.

jenkins tidak membangun tanpa alasan tertentu:
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

Kesalahan build lainnya: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-2827/13/pipeline

Terima kasih telah melaporkan!

@Dianiaya bisakah Anda menginstal Naginator+Plugin #2967 seperti yang sudah dibahas berkali-kali? (Harap buat snapshot sebelum mengubah Jenkins.)

hetzner-jenkins1 : kuota disk terlampaui

@Dianiaya bisakah Anda menginstal Naginator+Plugin #2967 seperti yang sudah dibahas berkali-kali? (Harap buat snapshot sebelum mengubah Jenkins.)

Akan melakukannya hari ini

hetzner-jenkins1: kuota disk terlampaui

@mpranj Saya menambahkan VM sebagai agen build saat hetzner-jenkins1 sedang down.

Saya membersihkan beberapa ruang di hetzner-jenkins1 dengan menjalankan docker system prune -a dan mengaktifkannya lagi.

Sepertinya ada lagi masalah banyak barang yang tidak dibersihkan oleh docker system prune -f . Kali ini driver penyimpanan bukan btrfs tetapi vfs . :bingung:

Saya menambahkan VM baru sebagai agen build saat hetzner-jenkins1 sedang down.

Idenya sekarang adalah kita tidak menggunakan wadah lagi tetapi hanya VM saja.

Saya membersihkan beberapa ruang di hetzner-jenkins1 dengan menjalankan sistem buruh pelabuhan Prune -a dan mengaktifkannya lagi.

Terima kasih banyak! Bisakah Anda juga membuat cronjob di sana? (pada VM, bukan pada wadah).

buat cronjob di sana?

Selesai.

@Dianiaya bisakah Anda menginstal Naginator+Plugin #2967 seperti yang sudah dibahas berkali-kali? (Harap buat snapshot sebelum mengubah Jenkins.)

Kita harus berpindah dari pekerjaan pipeline ke freestyle, jika kita menginginkan plugin naginator. Saya akan mencari alternatif.

Membangun pada VM jenkinsNode3VM saat ini gagal. Mereka tidak dapat menarik buruh pelabuhan:

unexpected EOF
script returned exit code 1

Saya menonaktifkannya untuk saat ini sampai seseorang dapat memperbaiki masalahnya.

[cronjob] Selesai.

Terima kasih!

Kita harus berpindah dari pekerjaan pipeline ke freestyle, jika kita menginginkan plugin naginator. Saya akan mencari alternatif.

Ya, ide yang bagus. Mungkin yang terbaik adalah mengkodekannya di Jenkinsfile. Jadi, jika pekerjaan/tahapan pembangunan yang bermasalah gagal, itu akan dicoba lagi. Bahwa tarikan buruh pelabuhan ini dicoba setidaknya dua kali karena ini adalah salah satu masalah yang paling sering terjadi.

Dibangun di atas VM jenkinsNode3VM saat ini gagal. Mereka tidak dapat menarik buruh pelabuhan:

@Dianiaya tolong perbaiki ini.

Dibangun di atas VM jenkinsNode3VM saat ini gagal. Mereka tidak dapat menarik buruh pelabuhan

Saya memperbaiki gambar buruh pelabuhan yang tidak dapat ditarik.

Terima kasih banyak! Itu selalu membantu jika Anda menulis apa yang salah dan bagaimana Anda memperbaikinya.

Saya tidak tahu apa yang salah, saya membuat gambar secara manual di agen. Karena agen tidak bisa menariknya.

Adapun Dockerfile (scripts/docker/debian/stretch) my Visual Code mengatakan memiliki 2 baris kosong di akhir, tetapi vim mengatakan hanya satu. Saya tidak tahu apakah itu harus melakukan sesuatu dengan kesalahan di atas, mungkin itu hanya VS .

Sepertinya kami memiliki masalah dengan registri buruh pelabuhan kami (#3316 tarikan buruh pelabuhan gagal dengan unexpected EOF ).

Karena debu setelah rilis telah diselesaikan dan tidak ada build yang terjadi, saya sarankan untuk menghentikan semuanya dan mencoba menghapus registri sepenuhnya. Setelah itu semua gambar harus dibangun kembali semoga bersih. Saya akan membuat cadangan data registri sebelum saya mulai hanya untuk memastikan, tetapi saya berharap bahwa awal yang bersih akan menghilangkan beberapa kesalahan yang kami alami.

Saya akan menunggu komentar apakah ada yang menentang itu sebelum saya mulai.

Saya pikir itu masalah di

(skrip/docker/debian/stretch)

gambar, karena itu adalah satu-satunya yang gagal.

Saya telah membangunnya secara manual lagi, tetapi pasti ada yang salah dengan gambar di registri.

Laporan Jenkins: jenkinsNode3VM (offline)

@Dianiaya akan sangat bagus jika Anda dapat mengatur beberapa cara pemantauan.

a7 (dan karenanya v2 dan i7 ) turun. Saya menghubungi admin.

EDIT markus2330: naik lagi

Karena pemadaman listrik yang direncanakan pada 08.07.2020 di TU Wien, admin kami berencana untuk mematikan semua server build pada hari sebelumnya (Selasa 7.7). Pembangunan akan sangat lambat selama waktu itu, jadi harap hanya dorong pada hari itu dalam kasus-kasus mendesak.

Server kembali online kecuali i7. Saya memberi tahu admin.

Ada pemadaman listrik lagi (tidak direncanakan) kemarin malam, sehingga semua server build sekarang mati. Admin sedang mengerjakannya.

EDIT 30 menit kemudian: semuanya, termasuk i7, sudah aktif lagi :rocket:

@ markus2330 tampaknya v2 dan i7 telah kehilangan akses internet baru-baru ini (mungkin selama pemadaman listrik?). Apakah Anda mengetahui perubahan konfigurasi yang seharusnya kami buat, karena antarmuka dikonfigurasi secara statis?

Saya tidak tahu tentang perubahan apa pun, hanya tentang bahwa komputer dihidupkan kembali setelah dua pemadaman listrik ini (satu direncanakan, yang lain tidak direncanakan).

Tapi Anda benar, saya juga melihat bahwa mereka berdua (tetapi tidak a7) tidak memiliki koneksi Internet lagi, meskipun mereka dapat dijangkau. Saya bertanya kepada admin kami tentang itu.

Mungkin kita memutuskan mereka dari Jenkins sampai masalah ini diperbaiki?

Terima kasih telah menghubungi admin! Saya memutuskan sambungan i7 dan v2 hingga masalah dapat diselesaikan. (Bangun tetap tidak berfungsi karena mereka tidak dapat menarik gambar buruh pelabuhan)

Seseorang mengubah sesuatu dengan router sekitar satu minggu yang lalu. Orang itu diberitahu dan mudah-mudahan akan segera memperbaikinya.

Mari kita biarkan mereka terputus untuk saat ini.

Masalah Internet teratasi sekarang dan saya juga menginstal pembaruan keamanan pada mesin ini.

@mpranj bisa tolong aktifkan lagi?

Terima kasih @markus2330.

Semua node sekarang kembali online.

Saya me-reboot server build untuk kernel PVE terbaru. Jenkins akan segera bangun.

aku pindah

• [ ] membuat pengiriman email jika build gagal lebih andal
• [ ] Gambar Docker tanpa pengguna Jenkins
• [ ] centOS/fedora/arch docker gambar
• [ ] paket centOS
• [ ] agen pembuat freebsd/openbsd/solaris

ke #3519 dan ditautkan ke #3519 di atas.

@robaerd sekarang juga memiliki akses ke a7/v2/i7 dan dapat menghubungi admin jika ada masalah.

Hanya laporan singkat tentang waktu pembuatan (pipa utama libelektra ):

• dengan a7 diaktifkan: 2h 29m 24s
• dengan a7 dinonaktifkan: 1h 35m 45s

Mengapa Jenkins menampilkan bahwa itu dimatikan? Akan lebih baik untuk selalu membaca di sini sebelumnya :wink:

Jenkins akan dimatikan, karena cadangan sistem penuh dan memformat ulang sistem file dari btrfs ke ext4.

Jenkins bangkit lagi

Jenkins CI akan offline untuk pemeliharaan mulai sekitar pukul 11:15 CET hari ini.

Kami akan melakukan beberapa tugas pencadangan dan pembersihan dan mencoba meningkatkan kinerja a7 .

Anda akan diberitahu lagi ketika pemeliharaan selesai.

Jenkins CI dan semua server build sudah aktif kembali. a7 seharusnya berkinerja jauh lebih baik sekarang, tetapi memiliki kapasitas penyimpanan yang lebih sedikit.

Silakan laporkan jika Anda mengalami kesalahan.

Jenkins CI dan agen build akan offline untuk pemeliharaan/pembaruan singkat.

EDIT: pembaruan selesai.

Server sedang down, saya selidiki.

Server sudah aktif lagi.

Pernyataan resmi tentang penyebabnya: "Ada masalah dengan PSU di server yang berdekatan yang menyebabkan server dimatikan; sekarang telah diperbaiki."

SSD di a7 penuh, menyebabkan semua build di atasnya gagal.

Saya akan mencoba mengosongkan beberapa ruang. Apakah aman untuk memutuskan a7 build agent dari jenkins untuk saat ini?

Terima kasih telah memeriksanya!

Saya akan mencoba mengosongkan beberapa ruang. Apakah aman untuk memutuskan agen build a7 dari jenkins untuk saat ini?

Tentu saja. Sebaliknya, tidak aman untuk tetap terhubung jika itu membuat semua build gagal.

Menjalankan docker system prune -a membersihkan sekitar 50% ruang lagi. Mungkin kita perlu mengadaptasi cronjob yang ada untuk menambahkan flag -a ?

Rumah jenkins juga menggunakan banyak ruang.

Pembuatan master (pipa penuh dengan paket deb dan pembuatan situs web) entah bagaimana masih gagal, meskipun semuanya terlihat hijau. Ada ide?

Pengunggahan paket focal deb ke community gagal pada file elektra_0.9.3.orig.tar.gz . Ini mungkin masalah izin pada file. Saya akan menghapusnya dari direktori untuk saat ini dan membiarkannya dibuat ulang pada proses berikutnya.

Entah bagaimana sshPublisher jika gagal tidak mengatur panggung menjadi merah.

Mungkin kita perlu mengadaptasi cronjob yang ada untuk menambahkan flag -a?

Apakah ada alasan mengapa Anda tidak melakukannya seperti ini? Jika tidak, sepertinya ide yang bagus.

Jenkins CI dan registri pada a7 akan offline untuk migrasi gambar menara pengawal ke versi baru. Hanya perlu beberapa menit.

EDIT: Pembaruan selesai dan Jenkins CI sudah aktif lagi

Jenkins dan agen akan turun sebentar untuk pembaruan.

EDIT: semuanya telah diperbarui dan aktif & berjalan kembali. Saya perlu memperbaiki masalah di mana a7 menggunakan paket buruh pelabuhan peregangan Debian alih-alih buster. Saya juga membersihkan beberapa ruang.

Build gagal karena tidak ada ruang pada a7 .

Membangun infrastruktur tidak akan tersedia selama beberapa menit untuk pemeliharaan.

Membangun infrastruktur tersedia lagi.