C'est encore arrivé 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 Pouvez-vous jeter un œil aux fichiers maven ?

Cette erreur se produit de manière aléatoire et pas à chaque build ?

Je ne pouvais que suggérer de mettre à jour le plugin maven-compiler-plugin de 3.6.0 à 3.8.1 et j'espère que la dépendance transitive sonar y est disponible. La dépendance sonar 1.7 est obsolète de toute façon depuis des années (2010)

Oui, ça arrive au hasard.

Avons-nous vraiment besoin de la dépendance au sonar ?

Pouvons-nous mettre à niveau vers maven-compiler-plugin 3.8.1 et toujours prendre en charge Apache Maven 3.3.9 ?

Avons-nous vraiment besoin de la dépendance au sonar ?

La dépendance sonar n'est pas utilisée directement par nous mais par le maven-compiler-plugin .

Pouvons-nous mettre à niveau vers maven-compiler-plugin 3.8.1 et toujours prendre en charge Apache Maven 3.3.9 ?

La version de maven et la version de maven-compiler-plugin n'ont aucune corrélation. Vous devriez pouvoir le mettre à jour sans problème

Merci, pourriez-vous mettre à jour la version ?

Il semble que la mise à niveau n'a pas aidé, la première version après la fusion du PR a déjà échoué :

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

Le build est-il multithread ? Cela expliquerait l'erreur (https://jira.apache.org/jira/browse/MDEP-518)

Voulez-vous dire si nous appelons maven plusieurs fois simultanément ? Cela pourrait être possible.

Alors c'est un problème maven ouvert malheureusement.

Le build Java est très simple, il serait dommage de ne pas avoir cette fiabilité. Peut-être avons-nous simplement oublié une dépendance au niveau de CMake (par exemple entre testjna_maven et la liaison ?).

S'il s'agit vraiment d'un problème interne à maven, une solution est décrite dans le dernier message du problème maven, pouvez-vous l'essayer ?

S'il s'agit vraiment d'un problème interne à maven, une solution est décrite dans le dernier message du problème maven, pouvez-vous l'essayer ?

Le dernier post décrit une extension qui modifie sévèrement le comportement de maven en termes de gestion des jar. Nous aurions juste une autre dépendance dans la construction qui n'est probablement pas très stable. De plus, nous nous limiterions probablement à la mise à niveau de maven à l'avenir, car cela modifie le comportement comme celui-ci. De plus, je n'ai actuellement pas les ressources pour corriger chaque travail de construction avec ceci

Comme dit précédemment, je ne pense pas que nous ayons besoin d'une telle extension car nos versions Java sont complètement standard.

Il est plus probable que deux processus maven soient démarrés en même temps. Il ne devrait pas être trop difficile d'éviter que JNI ne soit construit que si JNA a déjà été construit.

2967 contient maintenant une liste complète des problèmes, j'espère que nous pourrons résoudre ce problème bientôt pour avoir un problème de moins :+1:

arrivé dans https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/70/pipeline

Échec à nouveau dans le même PR https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/74/pipeline

a de nouveau échoué https://travis-ci.org/ElektraInitiative/libelektra/jobs/599129506

a de nouveau échoué https://travis-ci.org/ElektraInitiative/libelektra/jobs/599129506

en fait, ce travail de construction n'a pas échoué du tout

@sanssecours (ou @Chemin1 ): Comment fonctionne exactement la construction de jenkins en ce qui concerne les caches. Est-ce que chaque build charge une image docker et télécharge toutes les dépendances de maven lui-même dans le conteneur ? Ou existe-t-il un dossier général utilisé par toutes les versions pour réduire la charge du disque/réseau ?

Je ne connais aucun code spécial pour télécharger les packages Maven sur le serveur de build Jenkins. Je suppose que cmake utilise mvn pour télécharger les packages pour la construction, comme ce serait le cas si vous construisiez Elektra localement. Je ne suis pas vraiment familier avec la configuration de Jenkins, cependant.

Je suppose que cmake utilise mvn pour télécharger les packages pour la construction

mvn télécharge implicitement les dépendances lorsque jna est construit. Toute dépendance est généralement téléchargée dans un référentiel .m2 local sous le chemin home . Jenkins effectue-t-il des builds/téléchargements, etc. dans un conteneur docker en cours d'exécution local ou utilise-t-il un répertoire de construction temporaire standard à partir d'un jenkins ?

Jenkins effectue-t-il des builds/téléchargements, etc. dans un conteneur docker en cours d'exécution local ou utilise-t-il un répertoire de construction temporaire standard à partir d'un jenkins ?

Je sais seulement que nous ajoutons déjà Google Test à la plupart de nos images Docker. Par exemple, voici le code pertinent pour Debian Buster :

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

.

Comment fonctionne exactement la construction de jenkins en ce qui concerne les caches. Est-ce que chaque build charge une image docker et télécharge toutes les dépendances de maven lui-même dans le conteneur ? Ou existe-t-il un dossier général utilisé par toutes les versions pour réduire la charge du disque/réseau ?

Malheureusement, je n'ai pas la moindre idée.

@Mistreat En savez-vous plus à ce sujet ?

Je suis juste confus sur la façon dont docker interagit avec les répertoires jenkins. Le problème de ce problème ne se produit que si plusieurs instances Maven tentent de se télécharger dans le même répertoire lors de la résolution des dépendances. Cependant, si cela est fait via docker, cela ne devrait pas se produire à moins que les mêmes volumes ne soient montés pour toutes les images docker qui incluent le répertoire mvn. Cela expliquerait également pourquoi ce problème ne se produit que sur le serveur jenkins puisque travis utilise des machines virtuelles correctement encapsulées.

Cette ligne suggère au moins que les volumes sont montés mais je ne sais pas exactement comment cela se fait sur les jenkins car $PWD peut être n'importe quoi.

Cette ligne suggère au moins que les volumes sont montés mais je ne sais pas exactement comment cela se fait sur les jenkins car $PWD peut être n'importe quoi.

Je pense que c'est juste un tutoriel, pas ce qui se passe réellement sur nos jenkins. L'accès au miroir git local est le seul montage que je vois dans notre fichier Jenkins. Je ne pense pas qu'il y ait d'autres interactions directes avec le système de fichiers hôte. Les documents sont publiés via SSH et les artefacts sont stockés via archiveArtifacts . Il me semble moins probable que plusieurs instances de docker accèdent au même répertoire maven. Peut-être que quelque chose de différent se passe ?

en fait, ce travail de construction n'a pas échoué du tout

On dirait que Travis ne conserve pas la construction ayant échoué après une nouvelle tentative, du moins je ne la trouve plus non plus.

Comment fonctionne exactement la construction de jenkins en ce qui concerne les caches.

Cela n'a rien à voir avec Jenkins car il échoue également localement et sur Travis.

Le problème de ce problème ne se produit que si plusieurs instances Maven tentent de se télécharger dans le même répertoire lors de la résolution des dépendances.

C'est un pas dans la bonne direction.

Comme déjà dit, Elektra effectue au moins deux appels mvn lors de la construction (jni et jna). La dépendance entre eux est très probablement incorrecte, entraînant des exécutions simultanées. Veuillez étudier cela.

Cela n'a rien à voir avec Jenkins car il échoue également localement et sur Travis.

Ok, ce n'était pas clair pour moi.

Comme déjà dit, Elektra effectue au moins deux appels mvn lors de la construction (jni et jna). La dépendance entre eux est très probablement incorrecte, entraînant des exécutions simultanées. Veuillez étudier cela.

J'ai ouvert #3113

Observons si l'erreur se reproduit.

Avez-vous revu cette erreur ? Nous pourrions probablement le fermer et le rouvrir si une construction échoue

Je ne l'ai pas revu. Il semble donc que vous l'ayez corrigé :100:

@ markus2330 semble que cela s'est produit sur le maître maintenant. https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/master/35/pipeline

La sortie était : log.txt

Est-ce un échec temporaire que nous pouvons ignorer pour la version ?

Ce n'est peut-être pas temporaire [0] mais je pense que nous pouvons l'ignorer pour la version.

[0] #3269 semble avoir été temporaire car il y a eu une "réinitialisation de la connexion" mais ici je ne le vois pas et KDBTest.test_kdbGet_shouldPass:46 » Internal Sorry, module (null) issued error... ressemble beaucoup à quelque chose dans la KDB.

Le message d'erreur est complètement faux, c'est un problème pour @Piankero.

Je rouvre pour suivre ce nouveau problème (à l'avenir, il vaut mieux ouvrir de nouveaux problèmes, la réutilisation des problèmes est toujours quelque peu problématique).

Désolé, je ne voulais pas réutiliser les problèmes. J'ai jeté un coup d'œil dessus et j'ai pensé que c'était la même chose.

Pas besoin d'être désolé, c'est moi qui l'ai réutilisé :wink:

Le message d'erreur est complètement faux, c'est un problème pour @Piankero.

Je ne peux malheureusement pas reproduire cette erreur et je ne sais pas non plus comment cela peut réellement se produire car Elektra a renvoyé -1 à la liaison avec une "InternalError" (https://github.com/ElektraInitiative/libelektra/blob/09f2fdc2e33cf0ea0d20251f64c9485ccd7931c3/src/ bindings/jna/libelektra4j/src/main/java/org/libelektra/exception/mapper/ExceptionMapperService.java#L26-L29) mais n'est pas capable de le lire quelques lignes plus tard https://github.com/ElektraInitiative/libelektra /blob/09f2fdc2e33cf0ea0d20251f64c9485ccd7931c3/src/bindings/jna/libelektra4j/src/main/java/org/libelektra/exception/KDBException.java#L54-L57

Comme si la clé avec ses métadonnées avait été supprimée entre-temps. Cette erreur s'est-elle reproduite entre la publication et maintenant ?

Avez-vous une explication pourquoi le message d'erreur est si déformé?

Veuillez ajouter un test unitaire Java sur une erreur qui se produit dans Elektra (par exemple avec le plugin d'erreur). Le plugin d'erreur peut également être utile pour le tutoriel d'erreur que vous avez commencé à écrire.

Veuillez ajouter un test unitaire Java sur une erreur qui se produit dans Elektra (par exemple avec le plugin d'erreur). Le plugin d'erreur peut également être utile pour le tutoriel d'erreur que vous avez commencé à écrire.

Cette classe teste en fait chaque exception avec le plugin d'erreur.

Cela teste si les métadonnées sont correctement extraites.

Avez-vous une explication pourquoi le message d'erreur est si déformé?

Qu'est-ce que tu entends par "déformé" ? Tu veux dire les points à la fin ou quoi exactement ?

Cette classe teste en fait l'intégration de chaque exception avec le plugin d'erreur.

Uniquement si une exception est levée mais pas le message qu'elle affiche.

Cela teste si les métadonnées sont correctement extraites.

Ce test n'a également rien à voir avec les erreurs provenant d'Elektra.

Qu'est-ce que tu entends par "déformé" ?

Voir le titre de ce problème et 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)

Tu veux dire les points à la fin ou quoi exactement ?

Selon vous, quelle partie de ce message d'erreur est correcte ? De plus, c'est complètement cassé:

Internal Sorry, module (null) issued error..

Selon vous, quelle partie de ce message d'erreur est correcte ? De plus, c'est complètement cassé:

Ce message ici est juste une sortie tronquée de maven en tant que résumé et maven ajoute des points pour indiquer qu'il y a plus de texte à venir. Il le ferait pour tous les tests qui ont échoué. Cela n'a rien à voir avec le message réel.

Ce test n'a également rien à voir avec les erreurs provenant d'Elektra.

Il teste à l'unité l'extraction correcte des métadonnées et un test d'intégration pour cela semble un peu exagéré. Je peux ajouter un test d'intégration supplémentaire pour l'analyse de texte, mais je peux vous assurer que cela ne résoudra pas le problème existant. Cela semble être une erreur aléatoire pour moi et ne s'est jamais reproduite depuis...

Ce message ici est juste une sortie tronquée de maven en tant que résumé et maven ajoute des points pour indiquer qu'il y a plus de texte à venir. Il le ferait pour tous les tests qui ont échoué. Cela n'a rien à voir avec le message réel.

Alors maven mélange les mots ? Même si c'est le cas, cela n'explique pas le premier message cassé.

Il teste à l'unité l'extraction correcte des métadonnées et un test d'intégration pour cela semble un peu exagéré. Je peux ajouter un test d'intégration supplémentaire pour l'analyse de texte, mais je peux vous assurer que cela ne résoudra pas le problème existant. Cela semble être une erreur aléatoire pour moi et ne s'est jamais reproduite depuis...

Les « erreurs aléatoires » ne se produisent que s'il y a des problèmes de délai d'attente ou si le logiciel est défectueux. Je ne vois pas où dans ce cas il pourrait y avoir un timeout.

Mais concentrez-vous d'abord sur un tutoriel incroyable.