Wieder passiert 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

@Pianero Kannst du dir die Maven-Dateien ansehen?

Dieser Fehler tritt zufällig auf und nicht bei jedem Build?

Ich könnte nur vorschlagen, das Maven-Compiler-Plugin von 3.6.0 auf 3.8.1 zu aktualisieren und zu hoffen, dass die transitive Sonar-Abhängigkeit dort verfügbar ist. Die Abhängigkeit von Sonar 1.7 ist sowieso um Jahre veraltet (2010)

Ja, es passiert zufällig.

Brauchen wir die Sonarabhängigkeit überhaupt?

Können wir auf maven-compiler-plugin 3.8.1 upgraden und weiterhin Apache Maven 3.3.9 unterstützen?

Brauchen wir die Sonarabhängigkeit überhaupt?

Die Sonarabhängigkeit wird nicht direkt von uns verwendet, sondern von maven-compiler-plugin .

Können wir auf maven-compiler-plugin 3.8.1 upgraden und weiterhin Apache Maven 3.3.9 unterstützen?

Die Version von maven und die Version von maven-compiler-plugin haben überhaupt keine Korrelation. Sie sollten in der Lage sein, es ohne Probleme zu aktualisieren

Vielen Dank, könnten Sie bitte die Version aktualisieren?

Anscheinend hat das Upgrade nicht geholfen, der erste Build nach dem Zusammenführen des PR ist bereits fehlgeschlagen:

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

Ist der Build multithreaded? Es würde den Fehler erklären (https://jira.apache.org/jira/browse/MDEP-518)

Meinst du, wenn wir Maven mehrmals gleichzeitig aufrufen? Dies könnte möglich sein.

Dann ist dies leider ein offenes Maven-Problem .

Der Java-Build ist sehr einfach, es wäre schade, nicht so zuverlässig zu werden. Vielleicht haben wir einfach eine Abhängigkeit auf CMake-Ebene vergessen (zB zwischen testjna_maven und der Bindung?).

Wenn es sich wirklich um ein internes Problem in Maven handelt, wird im letzten Beitrag des Maven-Problems eine Lösung beschrieben, können Sie es versuchen?

Wenn es sich wirklich um ein internes Problem in Maven handelt, wird im letzten Beitrag des Maven-Problems eine Lösung beschrieben, können Sie es versuchen?

Der letzte Beitrag beschreibt eine Erweiterung, die das Verhalten von Maven in Bezug auf das Jar-Management stark verändert. Wir würden nur eine weitere Abhängigkeit in den Build bekommen, die wahrscheinlich nicht sehr stabil ist. Außerdem würden wir uns wahrscheinlich in Zukunft darauf beschränken, Maven zu aktualisieren, weil es das Verhalten so ändert. Außerdem habe ich derzeit nicht die Ressourcen, um jeden Build-Job damit zu patchen

Wie bereits erwähnt, glaube ich nicht, dass wir eine solche Erweiterung benötigen, da unsere Java-Builds vollständig Standard sind.

Wahrscheinlicher ist, dass zwei Maven-Prozesse gleichzeitig gestartet werden. Es sollte nicht allzu schwierig sein, zu vermeiden, dass JNI nur gebaut wird, wenn JNA bereits gebaut wurde.

2967 enthält jetzt eine vollständige Liste der Probleme, ich hoffe, wir können dies bald beheben, um ein Problem weniger zu haben :+1:

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

Wieder fehlgeschlagen in derselben PR https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/74/pipeline

erneut fehlgeschlagen https://travis-ci.org/ElektraInitiative/libelektra/jobs/599129506

erneut fehlgeschlagen https://travis-ci.org/ElektraInitiative/libelektra/jobs/599129506

Tatsächlich ist dieser Build-Job überhaupt nicht fehlgeschlagen

@sanssecours (oder @Chemin1 ): Wie genau funktioniert der Jenkins-Build in Bezug auf Caches? Lädt jeder Build ein Docker-Image und lädt alle Abhängigkeiten von Maven selbst in den Container herunter? Oder gibt es einen allgemeinen Ordner, der von allen Builds verwendet wird, um die Festplatten-/Netzwerklast zu reduzieren?

Mir ist kein spezieller Code zum Herunterladen von Maven-Paketen auf dem Jenkins-Build-Server bekannt. Ich würde davon ausgehen, dass cmake mvn verwendet, um die Pakete für den Build herunterzuladen, genau wie wenn Sie Elektra lokal bauen würden. Ich bin mit dem Jenkins-Setup jedoch nicht wirklich vertraut.

Ich würde davon ausgehen, dass cmake mvn verwendet, um die Pakete für den Build herunterzuladen

mvn lädt implizit Abhängigkeiten herunter, wenn jna erstellt wird. Jede Abhängigkeit wird normalerweise in ein lokales .m2-Repository unter dem Pfad home heruntergeladen. Führt Jenkins Builds/Downloads usw. in einem lokal ausgeführten Docker-Container durch oder verwendet es ein standardmäßiges temporäres Build-Verzeichnis von einem Jenkins?

Führt Jenkins Builds/Downloads usw. in einem lokal ausgeführten Docker-Container durch oder verwendet es ein standardmäßiges temporäres Build-Verzeichnis von einem Jenkins?

Ich weiß nur, dass wir Google Test bereits zu den meisten unserer Docker-Images hinzufügen. Hier ist zum Beispiel der relevante Code für Debian Buster:

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

.

Wie genau funktioniert der Jenkins-Build in Bezug auf Caches? Lädt jeder Build ein Docker-Image und lädt alle Abhängigkeiten von Maven selbst in den Container herunter? Oder gibt es einen allgemeinen Ordner, der von allen Builds verwendet wird, um die Festplatten-/Netzwerklast zu reduzieren?

Leider habe ich nicht die geringste Ahnung.

@Mißhandelt Weißt du mehr darüber?

Ich bin nur verwirrt, wie Docker mit den Jenkins-Verzeichnissen interagiert. Das Problem dieses Problems tritt nur auf, wenn mehrere Maven-Instanzen versuchen, beim Auflösen von Abhängigkeiten in dasselbe Verzeichnis herunterzuladen. Wenn dies jedoch über Docker erfolgt, sollte dies nicht passieren, es sei denn, die gleichen Volumes werden für alle Docker-Images bereitgestellt, die das mvn-Verzeichnis enthalten. Dies würde auch erklären, warum dieses Problem nur auf dem Jenkins-Server auftritt, da Travis VMs verwendet, die korrekt gekapselt sind.

Diese Zeile deutet zumindest darauf hin, dass Volumes gemountet sind, aber ich weiß nicht genau, wie es auf den Jenkins gemacht wird, da $PWD alles sein kann.

Diese Zeile deutet zumindest darauf hin, dass Volumes gemountet sind, aber ich weiß nicht genau, wie es auf den Jenkins gemacht wird, da $PWD alles sein kann.

Ich denke, das ist nur ein Tutorial, nicht das, was tatsächlich auf unseren Jenkins passiert. Der Zugriff auf den lokalen Git-Mirror ist der einzige Mount, den ich in unserer Jenkins-Datei sehe. Ich glaube nicht, dass es andere direkte Interaktionen mit dem Host-Dateisystem gibt. Dokumente werden über SSH veröffentlicht und Artefakte werden über archiveArtifacts gespeichert. Es scheint mir weniger wahrscheinlich, dass mehrere Docker-Instanzen auf dasselbe Maven-Verzeichnis zugreifen. Vielleicht geht da was anderes?

Tatsächlich ist dieser Build-Job überhaupt nicht fehlgeschlagen

Scheint, als würde Travis den fehlgeschlagenen Build nach dem erneuten Versuch nicht behalten, zumindest kann ich ihn auch nicht mehr finden.

Wie genau funktioniert der Jenkins-Build in Bezug auf Caches?

Es hat nichts mit Jenkins zu tun, da es auch lokal und auf Travis fehlschlägt.

Das Problem dieses Problems tritt nur auf, wenn mehrere Maven-Instanzen versuchen, beim Auflösen von Abhängigkeiten in dasselbe Verzeichnis herunterzuladen.

Das ist ein Schritt in die richtige Richtung.

Wie bereits gesagt, macht Elektra während des Builds mindestens zwei mvn-Aufrufe (jni und jna). Die Abhängigkeit zwischen ihnen ist höchstwahrscheinlich falsch, was zu gleichzeitigen Ausführungen führt. Bitte untersuchen Sie dies.

Es hat nichts mit Jenkins zu tun, da es auch lokal und auf Travis fehlschlägt.

Ok, das war mir nicht klar.

Wie bereits gesagt, macht Elektra während des Builds mindestens zwei mvn-Aufrufe (jni und jna). Die Abhängigkeit zwischen ihnen ist höchstwahrscheinlich falsch, was zu gleichzeitigen Ausführungen führt. Bitte untersuchen Sie dies.

Ich habe #3113 geöffnet

Lassen Sie uns beobachten, ob der Fehler erneut auftritt.

Haben Sie diesen Fehler erneut gesehen? Wir könnten es wahrscheinlich schließen und wieder öffnen, wenn ein Build fehlschlägt

Ich habe es nicht wieder gesehen. Also scheint es, als hättest du es behoben :100:

@ markus2330 scheint so, als wäre das jetzt auf master passiert. https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/master/35/pipeline

Ausgabe war: log.txt

Ist das ein vorübergehender Fehler, den wir für die Veröffentlichung ignorieren können?

Es ist vielleicht nicht vorübergehend [0], aber ich denke, wir können es für die Veröffentlichung ignorieren.

[0] #3269 scheint vorübergehend gewesen zu sein, weil es einen "Verbindungsreset" gab, aber hier sehe ich es nicht und KDBTest.test_kdbGet_shouldPass:46 » Internal Sorry, module (null) issued error... sieht sehr danach aus, als ob etwas in der KDB gewesen wäre.

Die Fehlermeldung ist komplett falsch, das ist ein Problem für @Pianero.

Ich öffne erneut, um dieses neue Problem zu verfolgen (öffne in Zukunft besser neue Probleme, die Wiederverwendung von Problemen ist immer etwas problematisch).

Tut mir leid, ich wollte Probleme nicht wiederverwenden. Ich habe es mir angeschaut und dachte es wäre das gleiche.

Kein Grund zur Entschuldigung, ich war derjenige, der es wiederverwendet hat :wink:

Die Fehlermeldung ist komplett falsch, das ist ein Problem für @Pianero.

Ich kann diesen Fehler leider nicht reproduzieren und habe auch keine Ahnung, wie das eigentlich passieren kann, da Elektra mit einem "InternalError" -1 an das Binding zurückgegeben hat (https://github.com/ElektraInitiative/libelektra/blob/09f2fdc2e33cf0ea0d20251f64c9485ccd7931c3/src/ Bindings/jna/libelektra4j/src/main/java/org/libelektra/exception/mapper/ExceptionMapperService.java#L26-L29), kann es aber ein paar Zeilen später nicht lesen https://github.com/ElektraInitiative/libelektra /blob/09f2fdc2e33cf0ea0d20251f64c9485ccd7931c3/src/bindings/jna/libelektra4j/src/main/java/org/libelektra/exception/KDBException.java#L54-L57

Als ob der Schlüssel mit seinen Metadaten zwischendurch gelöscht wurde. Ist dieser Fehler zwischen der Veröffentlichung und jetzt wieder aufgetreten?

Hast du eine Erklärung, warum die Fehlermeldung so verzerrt ist?

Bitte fügen Sie einen Java-Komponententest über einen Fehler hinzu, der in Elektra auftritt (zB mit dem Fehler-Plugin). Das Fehler-Plugin könnte auch für das Fehler-Tutorial nützlich sein, das Sie zu schreiben begonnen haben.

Bitte fügen Sie einen Java-Komponententest über einen Fehler hinzu, der in Elektra auftritt (zB mit dem Fehler-Plugin). Das Fehler-Plugin könnte auch für das Fehler-Tutorial nützlich sein, das Sie zu schreiben begonnen haben.

Diese Klasse testet tatsächlich jede Ausnahme mit dem Fehler-Plugin.

Dies testet, ob die Metadaten korrekt extrahiert werden.

Hast du eine Erklärung, warum die Fehlermeldung so verzerrt ist?

Was meinst du mit "verzerrt"? Meinst du die Punkte am Ende oder was genau?

Diese Klasse testet tatsächlich jede Ausnahme mit dem Fehler-Plugin.

Nur wenn eine Ausnahme ausgelöst wird, aber nicht, welche Nachricht sie darstellt.

Dies testet, ob die Metadaten korrekt extrahiert wurden.

Auch dieser Test hat nichts mit Fehlern von Elektra zu tun.

Was meinst du mit "verzerrt"?

Siehe Titel dieser Ausgabe und 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)

Meinst du die Punkte am Ende oder was genau?

Welchen Teil dieser Fehlermeldung halten Sie für richtig? Auch das ist komplett kaputt:

Internal Sorry, module (null) issued error..

Welchen Teil dieser Fehlermeldung halten Sie für richtig? Auch das ist komplett kaputt:

Diese Nachricht hier ist nur eine abgeschnittene Ausgabe von maven als Zusammenfassung und maven fügt Punkte hinzu, um anzuzeigen, dass noch mehr Text kommt. Es würde dies für alle Tests tun, die fehlgeschlagen sind. Mit der eigentlichen Botschaft hat das nichts zu tun.

Auch dieser Test hat nichts mit Fehlern von Elektra zu tun.

Es testet die korrekte Metadatenextraktion und ein Integrationstest dafür scheint ein bisschen übertrieben zu sein. Ich kann einen zusätzlichen Integrationstest für die Textanalyse hinzufügen, aber ich kann Ihnen versichern, dass dies das bestehende Problem nicht beheben wird. Für mich scheint es ein zufälliger Fehler zu sein, der seitdem nie wieder aufgetreten ist ...

Diese Nachricht hier ist nur eine abgeschnittene Ausgabe von maven als Zusammenfassung und maven fügt Punkte hinzu, um anzuzeigen, dass noch mehr Text kommt. Es würde dies für alle Tests tun, die fehlgeschlagen sind. Mit der eigentlichen Botschaft hat das nichts zu tun.

Maven mischt also um die Wörter herum? Selbst wenn dies der Fall ist, erklärt dies nicht die fehlerhafte erste Nachricht.

Es testet die korrekte Metadatenextraktion und ein Integrationstest dafür scheint ein bisschen übertrieben zu sein. Ich kann einen zusätzlichen Integrationstest für die Textanalyse hinzufügen, aber ich kann Ihnen versichern, dass dies das bestehende Problem nicht beheben wird. Für mich scheint es ein zufälliger Fehler zu sein, der seitdem nie wieder aufgetreten ist ...

"Zufällige Fehler" treten nur auf, wenn es Zeitüberschreitungsprobleme gibt oder die Software defekt ist. Ich sehe nicht, wo in diesem Fall ein Timeout sein könnte.

Aber konzentrieren Sie sich zuerst auf ein erstaunliches Tutorial.