Terjadi lagi https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/835/pipeline

WARNING: An illegal reflective access operation has occurred

WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)

WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1

WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations

WARNING: All illegal access operations will be denied in a future release

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.0:compile (default-compile) on project libelektra4j: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.6.0:compile failed: Plugin org.apache.maven.plugins:maven-compiler-plugin:3.6.0 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-compiler-plugin:jar:3.6.0 -> org.apache.maven:maven-core:jar:3.0 -> org.apache.maven:maven-settings-builder:jar:3.0 -> org.sonatype.aether:aether-util:jar:1.7: Failed to read artifact descriptor for org.sonatype.aether:aether-util:jar:1.7: Could not transfer artifact org.sonatype.aether:aether-parent:pom:1.7 from/to central (https://repo.maven.apache.org/maven2): /home/jenkins/.m2/repository/org/sonatype/aether/aether-parent/1.7/aether-parent-1.7.pom.part (No such file or directory) -> [Help 1]

[ERROR] 

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR] 

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

make[2]: *** [src/bindings/jna/CMakeFiles/jna.dir/build.make:75: src/bindings/jna/libelektra4j/target/libelektra4j-0.9.0.jar] Error 1

make[1]: *** [CMakeFiles/Makefile2:17116: src/bindings/jna/CMakeFiles/jna.dir/all] Error 2

@Piankero Bisakah Anda melihat file maven?

Kesalahan ini terjadi secara acak dan tidak dengan setiap build?

Saya hanya dapat menyarankan untuk memutakhirkan maven-compiler-plugin dari 3.6.0 ke 3.8.1 dan berharap ketergantungan sonar transitif tersedia di sana. Ketergantungan sonar 1.7 sudah ketinggalan zaman selama bertahun-tahun (2010)

Ya, itu terjadi secara acak.

Apakah kita membutuhkan ketergantungan sonar sama sekali?

Bisakah kita memutakhirkan ke maven-compiler-plugin 3.8.1 dan masih mendukung Apache Maven 3.3.9?

Apakah kita membutuhkan ketergantungan sonar sama sekali?

Ketergantungan sonar tidak digunakan oleh kami secara langsung tetapi oleh maven-compiler-plugin .

Bisakah kita memutakhirkan ke maven-compiler-plugin 3.8.1 dan masih mendukung Apache Maven 3.3.9?

Versi maven dan versi maven-compiler-plugin tidak memiliki korelasi sama sekali. Anda harus dapat meningkatkannya tanpa masalah

Terima kasih, bisakah Anda meningkatkan versinya?

Sepertinya upgrade tidak membantu, build pertama setelah menggabungkan PR sudah gagal:

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/848/pipeline

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project libelektra4j: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed: Plugin org.apache.maven.plugins:maven-compiler-plugin:3.8.1 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-compiler-plugin:jarScanning dependencies of target elektra-lineendings-objects

:3.8.1 -> org.apache.maven:maven-core:jar:3.0 -> org.apache.maven:maven-settings-builder:jar:3.0 -> org.sonatype.aether:aether-impl:jar:1.7: Failed to read artifact descriptor for org.sonatype.aether:aether-impl:jar:1.7: Could not transfer artifact org.sonatype.aether:aether-parent:pom:1.7 from/to central (https://repo.maven.apache.org/maven2): /home/jenkins/.m2/repository/org/sonatype/aether/aether-parent/1.7/aether-parent-1.7.pom.part (No such file or directory) -> [Help 1]

[ERROR] 

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR] 

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Scanning dependencies of target elektra-logchange-objects

Scanning dependencies of target elektra-list-objects

Apakah buildnya multithread? Itu akan menjelaskan kesalahannya ( https://jira.Apache.org/jira/browse/MDEP-518)

Apakah maksud Anda jika kita memanggil maven beberapa kali secara bersamaan? Ini mungkin.

Maka ini adalah masalah maven terbuka sayangnya.

Build Java sangat sederhana, sayang sekali tidak mendapatkan yang dapat diandalkan ini. Mungkin kita lupa ketergantungan pada level CMake (misalnya antara testjna_maven dan binding?).

Jika itu benar-benar masalah internal di maven, di posting terakhir masalah maven solusi dijelaskan, dapatkah Anda mencobanya?

Jika itu benar-benar masalah internal di maven, di posting terakhir masalah maven solusi dijelaskan, dapatkah Anda mencobanya?

Posting terakhir menjelaskan ekstensi yang sangat mengubah perilaku pakar dalam hal manajemen jar. Kami hanya akan mendapatkan ketergantungan lain ke dalam build yang mungkin tidak terlalu stabil. Kami juga mungkin akan membatasi kami dengan memutakhirkan pakar di masa mendatang karena itu mengubah perilaku seperti ini. Saya juga saat ini tidak memiliki sumber daya untuk menambal setiap pekerjaan build dengan ini

Seperti yang dikatakan sebelumnya, menurut saya kita tidak memerlukan ekstensi seperti itu karena build Java kita sepenuhnya standar.

Lebih mungkin adalah bahwa dua proses pakar dimulai pada waktu yang sama. Seharusnya tidak terlalu sulit untuk menghindari bahwa JNI hanya membangun jika JNA sudah dibangun.

2967 sekarang berisi daftar lengkap masalah, saya harap kami dapat segera memperbaikinya untuk mengurangi satu masalah :+1:

terjadi di https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/70/pipeline

Gagal lagi di PR yang sama https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/74/pipeline

gagal lagi https://travis-ci.org/ElektraInitiative/libelektra/jobs/599129506

gagal lagi https://travis-ci.org/ElektraInitiative/libelektra/jobs/599129506

sebenarnya pekerjaan build ini tidak gagal sama sekali

@sansecours (atau @Chemin1 ): Bagaimana tepatnya build jenkins bekerja dalam hal cache. Apakah setiap build memuat gambar buruh pelabuhan dan mengunduh semua dependensi pakar itu sendiri ke dalam wadah? Atau apakah ada folder umum yang digunakan oleh semua build untuk mengurangi beban disk/jaringan?

Saya tidak tahu tentang kode khusus untuk mengunduh paket Maven di server build Jenkins. Saya akan menganggap cmake menggunakan mvn untuk mengunduh paket-paket untuk pembangunan, sama seperti jika Anda membangun Elektra secara lokal. Saya tidak begitu akrab dengan pengaturan Jenkins.

Saya akan menganggap cmake menggunakan mvn untuk mengunduh paket-paket untuk build

mvn secara implisit mengunduh dependensi ketika jna dibangun. Ketergantungan apa pun biasanya diunduh di repositori .m2 lokal di bawah jalur home . Apakah jenkins melakukan build/unduh dll di wadah buruh pelabuhan yang berjalan lokal atau apakah itu menggunakan direktori build sementara standar dari jenkins?

Apakah jenkins melakukan build/unduh dll di wadah buruh pelabuhan yang berjalan lokal atau apakah itu menggunakan direktori build sementara standar dari jenkins?

Saya hanya tahu bahwa kami telah menambahkan Google Test ke sebagian besar gambar Docker kami. Sebagai contoh, berikut adalah kode yang relevan untuk Debian Buster:

https://github.com/ElektraInitiative/libelektra/blob/990b866c70ebf42448f633b6f0c9d2bb36a85102/scripts/docker/debian/buster/Dockerfile#L87 -L94

.

Bagaimana tepatnya build jenkins bekerja dalam hal cache. Apakah setiap build memuat gambar buruh pelabuhan dan mengunduh semua dependensi pakar itu sendiri ke dalam wadah? Atau apakah ada folder umum yang digunakan oleh semua build untuk mengurangi beban disk/jaringan?

Sayangnya, saya tidak memiliki petunjuk sedikit pun.

@Dianiaya Apakah Anda tahu lebih banyak tentang ini?

Saya hanya bingung bagaimana buruh pelabuhan berinteraksi dengan direktori jenkins. Masalah masalah ini hanya terjadi jika beberapa contoh pakar mencoba mengunduh ke direktori yang sama saat menyelesaikan dependensi. Namun jika ini dilakukan melalui buruh pelabuhan, ini tidak akan terjadi kecuali volume yang sama dipasang untuk semua gambar buruh pelabuhan yang menyertakan direktori mvn. Ini juga akan menjelaskan mengapa masalah ini hanya terjadi di server jenkins karena travis menggunakan VM yang dienkapsulasi dengan benar.

Baris ini menunjukkan setidaknya bahwa volume dipasang tetapi saya tidak tahu persis bagaimana hal itu dilakukan pada jenkins karena $PWD dapat berupa apa saja.

Baris ini menyarankan setidaknya bahwa volume dipasang tetapi saya tidak tahu persis bagaimana hal itu dilakukan pada jenkins karena $PWD bisa berupa apa saja.

Saya pikir itu hanya tutorial, bukan apa yang sebenarnya terjadi di jenkins kami. Akses ke mirror git lokal adalah satu-satunya mount yang saya lihat di Jenkinsfile. Saya tidak berpikir ada interaksi langsung lainnya dengan sistem file Host. Dokumen diterbitkan melalui SSH dan artefak disimpan melalui archiveArtifacts . Tampaknya bagi saya, beberapa instance buruh pelabuhan mengakses direktori maven yang sama. Mungkin sesuatu yang berbeda sedang terjadi?

sebenarnya pekerjaan build ini tidak gagal sama sekali

Sepertinya Travis tidak menyimpan build yang gagal setelah mencoba lagi, setidaknya saya juga tidak dapat menemukannya lagi.

Bagaimana tepatnya build jenkins bekerja dalam hal cache.

Ini tidak ada hubungannya dengan Jenkins karena juga gagal secara lokal dan di Travis.

Masalah masalah ini hanya terjadi jika beberapa contoh pakar mencoba mengunduh ke direktori yang sama saat menyelesaikan dependensi.

Ini adalah langkah ke arah yang benar.

Seperti yang telah dikatakan, Elektra melakukan setidaknya dua panggilan mvn selama pembuatan (jni dan jna). Ketergantungan di antara mereka kemungkinan besar salah, yang mengarah ke eksekusi bersamaan. Tolong selidiki ini.

Ini tidak ada hubungannya dengan Jenkins karena juga gagal secara lokal dan di Travis.

Oke, ini tidak jelas bagi saya.

Seperti yang telah dikatakan, Elektra melakukan setidaknya dua panggilan mvn selama pembuatan (jni dan jna). Ketergantungan di antara mereka kemungkinan besar salah, yang mengarah ke eksekusi bersamaan. Tolong selidiki ini.

Saya membuka #3113

Mari kita amati jika kesalahan terjadi lagi.

Pernahkah Anda melihat kesalahan ini lagi? Kami mungkin bisa menutupnya dan membukanya kembali jika build gagal

Saya tidak melihatnya lagi. Jadi sepertinya Anda memperbaikinya :100:

@ markus2330 sepertinya ini terjadi pada master sekarang. https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/master/35/pipeline

Outputnya adalah: log.txt

Apakah itu kegagalan sementara yang bisa kita abaikan untuk rilis?

Ini mungkin tidak sementara [0] tapi saya pikir kita bisa mengabaikannya untuk rilis.

[0] #3269 tampaknya bersifat sementara karena ada beberapa "reset koneksi" tetapi di sini saya tidak melihatnya dan KDBTest.test_kdbGet_shouldPass:46 » Internal Sorry, module (null) issued error... sepertinya ada sesuatu di KDB.

Pesan kesalahan benar-benar salah, ini adalah masalah untuk @Piankero.

Saya membuka kembali untuk melacak masalah baru ini (di masa depan lebih baik membuka masalah baru, menggunakan kembali masalah selalu agak bermasalah).

Maaf, saya tidak ingin menggunakan kembali masalah. Aku meliriknya dan berpikir itu sama.

Tidak perlu minta maaf, sayalah yang menggunakannya kembali :wink:

Pesan kesalahan benar-benar salah, ini adalah masalah untuk @Piankero.

Sayangnya saya tidak dapat mereproduksi kesalahan ini dan juga tidak tahu bagaimana ini sebenarnya bisa terjadi karena Elektra mengembalikan -1 ke pengikatan dengan "InternalError" (https://github.com/ElektraInitiative/libelektra/blob/09f2fdc2e33cf0ea0d20251f64c9485ccd7931c3/src/ binding/jna/libelektra4j/src/main/java/org/libelektra/exception/mapper/ExceptionMapperService.java#L26-L29) tetapi tidak dapat membacanya beberapa baris kemudian https://github.com/ElektraInitiative/libelektra /blob/09f2fdc2e33cf0ea0d20251f64c9485ccd7931c3/src/bindings/jna/libelektra4j/src/main/java/org/libelektra/exception/KDBException.java#L54-L57

Seolah-olah kunci dengan metadatanya telah dihapus di antaranya. Apakah kesalahan ini terjadi lagi di antara rilis dan sekarang?

Apakah Anda memiliki penjelasan mengapa pesan kesalahan begitu terdistorsi?

Harap tambahkan pengujian unit Java tentang kesalahan yang terjadi di Elektra (misalnya dengan plugin kesalahan). Plugin kesalahan mungkin juga berguna untuk tutorial Kesalahan yang Anda mulai tulis.

Harap tambahkan pengujian unit Java tentang kesalahan yang terjadi di Elektra (misalnya dengan plugin kesalahan). Plugin kesalahan mungkin juga berguna untuk tutorial Kesalahan yang Anda mulai tulis.

Kelas ini sebenarnya integrasi menguji setiap pengecualian dengan plugin kesalahan.

Ini menguji apakah metadata diekstraksi dengan benar.

Apakah Anda memiliki penjelasan mengapa pesan kesalahan begitu terdistorsi?

Apa yang Anda maksud dengan "distorsi"? Apakah maksud Anda titik-titik di akhir atau apa sebenarnya?

Kelas ini sebenarnya integrasi menguji setiap pengecualian dengan plugin kesalahan.

Hanya jika pengecualian dilempar tetapi bukan pesan yang dibuatnya.

Ini menguji apakah metadata diekstraksi dengan benar.

Tes ini juga tidak ada hubungannya dengan kesalahan yang berasal dari Elektra.

Apa yang Anda maksud dengan "distorsi"?

Lihat judul masalah ini dan log.txt :

Sorry, module (null) issued error (null):
(null)
Configfile: user/sw/tests/jna/1

    at org.libelektra.KDBTest.test_kdbGet_shouldPass(KDBTest.java:46)

Apakah maksud Anda titik-titik di akhir atau apa sebenarnya?

Bagian mana dari pesan kesalahan ini yang Anda yakini benar? Juga ini benar-benar rusak:

Internal Sorry, module (null) issued error..

Bagian mana dari pesan kesalahan ini yang Anda yakini benar? Juga ini benar-benar rusak:

Pesan ini di sini hanyalah keluaran terpotong dari maven sebagai ringkasan dan maven menambahkan titik untuk menunjukkan bahwa ada lebih banyak teks yang akan datang. Itu akan melakukan itu untuk semua tes yang gagal. Ini tidak ada hubungannya dengan pesan yang sebenarnya.

Tes ini juga tidak ada hubungannya dengan kesalahan yang berasal dari Elektra.

Unit ini menguji ekstraksi metadata yang benar dan tes integrasi untuk ini tampaknya sedikit berlebihan. Saya dapat menambahkan tes integrasi ekstra untuk penguraian teks tetapi saya dapat meyakinkan Anda bahwa ini tidak akan memperbaiki masalah yang ada. Tampaknya menjadi kesalahan acak bagi saya dan tidak pernah terjadi lagi sejak itu ...

Pesan ini di sini hanyalah keluaran terpotong dari maven sebagai ringkasan dan maven menambahkan titik untuk menunjukkan bahwa ada lebih banyak teks yang akan datang. Itu akan melakukan itu untuk semua tes yang gagal. Ini tidak ada hubungannya dengan pesan yang sebenarnya.

Jadi pakar mengocok kata-kata? Bahkan jika itu tidak menjelaskan pesan pertama yang rusak.

Unit ini menguji ekstraksi metadata yang benar dan tes integrasi untuk ini tampaknya sedikit berlebihan. Saya dapat menambahkan tes integrasi ekstra untuk penguraian teks tetapi saya dapat meyakinkan Anda bahwa ini tidak akan memperbaiki masalah yang ada. Tampaknya menjadi kesalahan acak bagi saya dan tidak pernah terjadi lagi sejak itu ...

"Kesalahan acak" hanya terjadi jika ada masalah batas waktu atau perangkat lunak rusak. Saya tidak melihat di mana dalam hal ini mungkin ada batas waktu.

Tetapi berkonsentrasilah pada tutorial yang luar biasa terlebih dahulu.