Selon le titre: J'essaie de lancer le test automatisé Maven de l'esclave Jenkins conteneurisé et, après avoir lutté contre cela pendant une semaine, je suis à court d'idées. Il fonctionne tel quel sur une instance AWS avec 4G de RAM mais dans un conteneur illimité (sur RAM et sur le processeur), il échoue avec le message d'erreur ci-dessous. Les seules circonstances dans lesquelles il s'exécute sont le moment où je désactive le forking pour le plug-in Failsafe mais ce n'est pas une option pour l'avenir.
J'ai essayé toutes sortes d'options Java/Maven/Failsafe/Surefire que j'ai pu trouver avec Google, mais aucune chance (comme l'ajout d'options globales Java -Xmx et également par plugin dans pom.xml).
Quelqu'un at-il couru avec succès comme ça?
Il semblerait que cela devrait être beaucoup plus facile à gérer, mais j'aurais déjà tiré tous les cheveux de ma tête si j'en avais. Je n'aime toujours pas l'idée d'admettre la défaite. S'il vous plaît aider!
Voici les sauvegardes que le plugin crée après une erreur:
fail-safe-summary.xml:
<?xml version="1.0" encoding="UTF-8"?>
<failsafe-summary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="https://maven.Apache.org/surefire/maven-sure
fire-plugin/xsd/failsafe-summary.xsd" result="254" timeout="false">
<completed>0</completed>
<errors>0</errors>
<failures>0</failures>
<skipped>0</skipped>
<failureMessage>org.Apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM cras
h or System.exit called?
Command was /bin/sh -c cd /var/lib/jenkins/workspace/ui_acceptance_test_chrome_docker_freestyle && /usr/lib/jvm/Java-1.8-openjdk/jre/bin/ja
va -Dfile.encoding=UTF-8 -jar /var/lib/jenkins/workspace/ui_acceptance_test_chrome_docker_freestyle/target/surefire/surefirebooter81206735832436906
05.jar /var/lib/jenkins/workspace/ui_acceptance_test_chrome_docker_freestyle/target/surefire 2017-10-10T15-02-35_189-jvmRun1 surefire59539140137458
58339tmp surefire_03559885505222114015tmp
Error occurred in starting fork, check output in log
Process Exit Code: 1
at org.Apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.Java:686)
at org.Apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.Java:535)
at org.Apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.Java:280)
at org.Apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.Java:245)
at org.Apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.Java:1124)
at org.Apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.Java:954)
at org.Apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.Java:832)
at org.Apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.Java:134)
at org.Apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.Java:207)
at org.Apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.Java:153)
at org.Apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.Java:145)
at org.Apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.Java:116)
at org.Apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.Java:80)
at org.Apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.Java:51)
at org.Apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.Java:128)
at org.Apache.maven.DefaultMaven.doExecute(DefaultMaven.Java:307)
at org.Apache.maven.DefaultMaven.doExecute(DefaultMaven.Java:193)
at org.Apache.maven.DefaultMaven.execute(DefaultMaven.Java:106)
at org.Apache.maven.cli.MavenCli.execute(MavenCli.Java:863)
at org.Apache.maven.cli.MavenCli.doMain(MavenCli.Java:288)
at org.Apache.maven.cli.MavenCli.main(MavenCli.Java:199)
at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:62)
at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:43)
at Java.lang.reflect.Method.invoke(Method.Java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.Java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.Java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.Java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.Java:356)
</failureMessage>
</failsafe-summary>
2017-10-10T15-02-35_189-jvmRun1.dump:
# Created on 2017-10-10T15:02:36.303
Killing self fork JVM. Maven process died.
Essayez de passer à Surefire 1.18.1. J'ai rencontré ce problème ce soir et y ai passé quelques heures. Jusqu'à présent, il est difficile de comprendre pourquoi les nouvelles versions de Surefire se développent sous Docker.
* Mettre à jour *
J'avais un problème avec Alpine Linux, mais lorsque j'utilisais une image de base Ubuntu ou Debian, tout allait bien. Ainsi, quelque chose dans la version 1.21 rompt la compatibilité avec certains systèmes d'exploitation.
J'ai rencontré le même problème dans l'environnement suivant: image de docker d'Alpine 3.7, version 2.21.0 du plugin maven surefire.
La cause fondamentale de cela est décrite dans SUREFIRE-1422 : surefire essaie d'utiliser ps -p
pour vérifier le processus créé. La solution pour moi était d'ajouter procps:
RUN apk add --no-cache procps
Je sais que cela fait longtemps, mais j'ajouterai ma solution au problème qui m'a pris plus d'une journée à FIX.
Problème: j'effectue mes tests d'intégration dans le PaaS dans un conteneur Docker et je n'ai aucun contrôle sur l'allocation de mémoire pour mon processus. Le comportement par défaut est pour failafe/surfire de bifurquer une machine virtuelle Java et d’exécuter les tests dessus. Je ne pouvais pas trouver un moyen de contrôler l'allocation de mémoire pour cette machine virtuelle Java fourchue et les tests échouaient avec l'erreur "Une erreur s'est produite lors du démarrage de la fourche" a également vu "Le forked VM s'est terminé sans dire correctement au revoir docker" dans les journaux en fonction sur quelle version de fail-safe j'essayais.
Solution: Ma solution consistait à désactiver le forking de la machine virtuelle et à exécuter tous les tests dans la même machine virtuelle que le processus principal principal. Ce n'est peut-être pas la solution idéale pour beaucoup, mais cela ne fonctionnerait que si vous pouviez seulement contrôler l'allocation de mémoire maximale du processus principal maven.
Pour désactiver le forking, il suffit de définir le forkMode dans la configuration:
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<configuration>
<forkMode>none</forkMode>
</configuration>
.....
UPDATE: Depuis que cette solution a été trouvée, il semble que vous puissiez désormais transmettre des paramètres à la machine virtuelle Java créée, de sorte que la solution précédente ne devrait plus être utilisée.
Dans la documentation maven sous Forked Test Execution:
Avec la propriété
argLine
, vous pouvez spécifier des paramètres supplémentaires pour être transmis au processus JVM créé, tels que les paramètres de mémoire. Système les variables de propriété du processus maven principal sont transmises au processus fourchu aussi bien. De plus, vous pouvez utiliser l'élémentsystemPropertyVariables
pour spécifier les variables et les valeurs à ajouter à les propriétés du système pendant l'exécution du test.
Nous avons soudainement rencontré exactement le même problème, mais uniquement sur notre pipeline CI/CD (gitlab) . Le message d'erreur était le suivant:
error occurred in starting fork, check output in log
Process Exit Code: 1
org.Apache.maven.surefire.booter.SurefireBooterForkException:
The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
Il s'est avéré que cela était lié à une nouvelle version de l'image du menu fixe OpenJDK.
La définition de la propriété useSystemClassLoader
sur false a résolu le problème:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
<configuration>
<includes>
<include>**/*Test.Java</include>
</includes>
<useSystemClassLoader>false</useSystemClassLoader>
</configuration>
</plugin>
Il suffit de frapper le même problème lors de la construction de maven: 3.5.4-jdk-8 avec surefire 2.21.0 . Améliorer le surefire n'a pas aidé non plus, mais la désactivation de la fourche a finalement permis de résoudre le problème.
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.1</version>
<configuration>
<forkCount>0</forkCount>
</configuration>
</plugin>
Nous avions le même problème lorsque nous utilisions une chaussure à ressort avec la version 2.21.0 de Surefire sur Alpine avec docker (zenika/Alpine-maven). Comme mentionné précédemment, le passage à la version 2.18.1 pourrait être une option et résoudre le problème de la terminaison vm forké, mais a généré de nouveaux problèmes d'incompatibilités entre les différentes versions de slf4j. Nous avons donc procédé à une mise à niveau explicite de la version 2.22.1 de Surefire, qui a résolu le problème dans notre cas.
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.1</version>
</plugin>