Terima kasih atas ringkasan masalah ini!

Apakah mungkin menonaktifkan pekerjaan hanya di tempat yang gagal?

Untuk crypto dan fcrypt plugin @mpranj menunjukkan bahwa gpg-agent mungkin gagal dalam kasus beban server yang tinggi. Mungkin kita bisa membuat pekerjaan build terpisah untuk pengujian plugin crypto dan fcrypt ? Sehingga perkembangan lainnya tidak terhalang.

Terima kasih atas masukannya!

Memisahkan pekerjaan yang bermasalah dapat mempersingkat siklus rekondisi. Tapi saya pikir sudah jelas bahwa kami sama sekali tidak ingin membangun ulang secara manual. Jadi kami punya pilihan:

• membuatnya lebih andal
• beberapa loop otomatis yang mencoba ulang kesalahan tersebut
• menonaktifkan tes (ketika seseorang mengerjakan bagian ini, dia perlu mengaktifkannya lagi)

Bagaimana menurut anda?

• membuatnya lebih andal

hampir tidak mungkin selama kita menggunakan gpg-agent (yang merepotkan dalam pekerjaan batch)

• beberapa loop otomatis yang mencoba ulang kesalahan tersebut

Ini terasa kotor bagiku.

• menonaktifkan tes (ketika seseorang mengerjakan bagian ini, dia perlu mengaktifkannya lagi)

Tampaknya menjadi opsi yang paling tidak menyebabkan ketidaknyamanan, meskipun memiliki tes regresi manual juga tidak bagus.

Seperti yang dibahas dalam pertemuan: kita harus menonaktifkan tes.

Alternatif juga dibahas dalam pertemuan tersebut: Menggunakan ctest --rerun-failed

Menjalankan ctest membuat file <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log (stempel waktu hanya digunakan dalam mode Dashboard). File ini juga digunakan oleh ctest --rerun-failed (lihat Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f). Ini hanya berisi nomor dan nama tes yang terakhir kali gagal.

Proposal saya akan memanggil ctest seperti sebelumnya. Jika jika keluar tidak berhasil, gunakan grep pada LastTestsFailed.log untuk memeriksa apakah salah satu tes yang tercantum di atas gagal. Dan baru kemudian gunakan ctest --rerun-failed . Ini menyebabkan lebih sedikit duplikasi / keluaran yang membingungkan.

Tetapi jika masalahnya benar-benar adalah beban server yang tinggi itu tidak akan banyak membantu. Sebaliknya kita bisa mencoba ctest --test-load . Ini akan menyebabkan ctest menjaga beban CPU di bawah ambang tertentu.

IMO masih pilihan terbaik adalah menonaktifkan pengujian dan membuat pekerjaan build kecil yang hanya menginstal dependensi yang diperlukan oleh plugin / library ini, hanya mengompilasi apa yang diperlukan dan hanya menjalankan pengujian yang bermasalah. Dengan cara itu kita bisa mendapatkan runtime mungkin selesai untuk beberapa menit, dalam hal ini restart manual akan dapat diterima. Sebagai perbandingan, pekerjaan FreeBSD kami saat ini membutuhkan waktu sekitar 10 menit (7 menit build, 2 menit pengujian, 1 menit lainnya) untuk menjalankan ~ 200 pengujian.

PS. Tidak yakin tentang penyiapan kami, tetapi memulai ulang pipeline jenkins dari tahap tertentu seharusnya dapat dilakukan

Alternatif juga dibahas dalam pertemuan tersebut: Menggunakan ctest --rerun-gagal

Terima kasih telah memeriksanya!

Tetapi jika masalahnya benar-benar adalah beban server yang tinggi itu tidak akan banyak membantu. Sebagai gantinya kita dapat mencoba ctest --test-load.

@ingwinlu melakukan banyak pekerjaan ke arah ini. Server kami memiliki throughput tertinggi dengan beban tinggi. Yaitu kami akan memperlambat pengujian kami dengan opsi seperti itu.

IMO masih pilihan terbaik adalah menonaktifkan pengujian dan membuat pekerjaan build kecil yang hanya menginstal file

Kasus uji modular sangat sulit dicapai dan dipelihara. @ingwinlu bekerja keras untuk itu. Saya pikir kita tidak dapat melakukan upaya ini lagi hanya untuk beberapa tes yang tidak dapat diandalkan.

PS. Tidak yakin tentang penyiapan kami, tetapi memulai ulang pipeline jenkins dari tahap tertentu seharusnya dapat dilakukan

Itu bagus. Tapi saya tidak melihat tombol restart di GUI kami. Apakah kami memerlukan plugin lain atau versi yang lebih baru? @ingwinlu mencoba menambahkan "jenkins build * please" untuk semua langkah pipeline, sayangnya, tidak berhasil.

Sepertinya kami masih mengalami kegagalan (dbus lihat # 2532)

Bagaimana dengan mengecualikan kasus uji dbus untuk build Mac?

Sepertinya kami masih mengalami kegagalan (dbus lihat # 2532)

Ya, kami melakukannya.

gcc --version

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

Apple LLVM version 10.0.1 (clang-1001.0.46.4)

Target: x86_64-apple-darwin18.5.0

Thread model: posix

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

(...)

DBUSRECV TESTS

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

testing prerequisites

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

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

test commit

test adding keys

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

    compared: expectedKeyName and keyName (test_callbackKey)

test adding keys

testmod_dbusrecv Results: 34 Tests done — 1 error.

Apakah Anda dapat memperbanyaknya secara lokal?

Kami masih belum tahu mengapa masalah ini terjadi secara sporadis. Jika Anda memiliki masukan, itu akan sangat bagus.

Mungkin kita bisa mengecualikan pengujian dari pekerjaan build yang bermasalah? Atau apakah testcases dbus * gagal pada setiap pekerjaan build yang dijalankan?

Apakah Anda dapat memperbanyaknya secara lokal?

Sayangnya tidak. Saya menggunakan Ubuntu.

Mungkin kita bisa mengecualikan pengujian dari pekerjaan build yang bermasalah? Atau apakah testcases dbus * gagal pada setiap pekerjaan build yang dijalankan?

Saya baru saja memulai ulang pekerjaan pembuatan untuk melihat apakah itu terjadi lagi.

Tolong tetapkan kembali saya jika perlu.

Saya sekarang menerapkan percobaan ulang otomatis ctest di # 3224. Jika Anda masih mengalami kegagalan sementara dari rangkaian pengujian, buka kembali masalahnya. (Kami dapat meningkatkan jumlah percobaan.)

Untuk kegagalan Jenkins / Docker lainnya, kita perlu mencari solusi lain tetapi pertama-tama kita perlu melakukan migrasi. Jadi silakan lanjutkan untuk memulai kembali pekerjaan dalam kasus ini.