java - Jenkins+Play 1.2.4: problemas con los archivos de bloqueo de cobertura/informe

playframework playframework-1.x (5)

Tenemos una aplicación Play 1.2.4 y obtuvimos Jenkins (en Ubuntu) para la aplicación. Estamos teniendo problemas con Cobertura.

Después de ejecutar las pruebas (con éxito), de vez en cuando, obtenemos el siguiente error:

--------------------------------------- java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at net.sourceforge.cobertura.util.FileLocker.lock(FileLocker.java:124) at play.modules.cobertura.CoberturaPlugin$CoberturaPluginShutdownThread.run(Unknown Source) Caused by: java.nio.channels.OverlappingFileLockException at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(FileChannelImpl.java:1166) at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(FileChannelImpl.java:1068) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:824) at java.nio.channels.FileChannel.lock(FileChannel.java:860) ... 6 more --------------------------------------- Unable to get lock on /var/lib/jenkins/jobs/project/workspace/cobertura.ser.lock: null This is known to happen on Linux kernel 2.6.20. Make sure cobertura.jar is in the root classpath of the jvm process running the instrumented code. If the instrumented code is running in a web server, this means cobertura.jar should be in the web server''s lib directory. Don''t put multiple copies of cobertura.jar in different WEB-INF/lib directories. Only one classloader should load cobertura. It should be the root classloader. --------------------------------------- lock file could not be deleted

Esto no parece "romper la compilación", pero más adelante en la compilación, obtenemos lo siguiente (lo que hace que los informes de cobertura fallen)

Publishing Cobertura coverage report... No coverage results were found using the pattern ''test-result/code-coverage/coverage.xml'' relative to ''/var/lib/jenkins/jobs/project/workspace''. Did you enter a pattern relative to the correct directory? Did you generate the XML report(s) for Cobertura? Build step ''Publish Cobertura Coverage Report'' changed build result to FAILURE

Ejecutar una compilación subsiguiente manualmente generalmente pasa.

De acuerdo con la cobertura de código cero con cobertura 1.9.2 pero las pruebas están funcionando , intenté configurar -Dcobertura.use.java.nio = false después de jugar auto-test -command.

Como este error estaba ocurriendo solo de vez en cuando, no estoy totalmente seguro de si esto ayudó. Pero después de eso, tenemos un problema con el juego auto-prueba colgando:

... Executing /opt/play-1.2.4/play auto-test "/var/lib/jenkins/jobs/project/workspace" -Dcobertura.use.java.nio=false [workspace] $ /opt/play-1.2.4/play auto-test "/var/lib/jenkins/jobs/project/workspace" -Dcobertura.use.java.nio=false <build stuck here for a couple of days>

Como nada ha sido totalmente determinista, es un poco difícil decir acerca de las causalidades aquí. (Esto parece suceder después de una o dos compilaciones después del reinicio de jenkins / server)

Actualmente estoy considerando desactivar Cobertura en nuestro proyecto, pero si alguien tiene otras ideas, sería genial =)

¿Has establecido

%test.play.tmp=none

en su archivo application.conf?

-Dcobertura.use.java.nio = false Parece que el anterior requiere cambiar a verdadero para poder usar el bloqueo de archivos a medida que se explica su mensaje de error.

Además, en algún lugar la aplicación probablemente requiera agregar la ruta de acceso de clase completa para cobertura.

appears que está utilizando algo similar a un archivo COF (constantemente abierto), el mensaje de error se refiere a un archivo que existe, pero las regiones del archivo están bloqueadas en la unidad, no simplemente en el archivo.

Claramente, esto se debe a problemas de bloqueo de JVM en la implementación de JVM o, mejor dicho, en la forma en que está implementando su JAR de cobertura.

Jenkins puede engendrar una gran cantidad de hilos de JVM, y si cobetura está en tu classpath global, es posible que ocurran algunas colisiones extrañas.

Supongo, en última instancia, que esto se debe atribuir a un error menor en la cobertura (a menos que el bloqueo del archivo corbertura complejo resuelva otro problema más importante).

De acuerdo con el código fuente de FileLock de Cobertura (cobertura / src / main / java / net / sourceforge / cobertura / util / FileLocker.java), existen varios problemas con respecto a la carga de múltiples JVM del contenedor de Cobertura.

Para resolverlo, asegúrese de que solo haya una copia y una aplicación iniciando y usando Corbetura.

La razón por la que su implementación de VM lo solucionó, lo más probable es que haya disminuido la cantidad de variabilidad en la forma en que se puede cargar cobetrura. También quizás esté reiniciando su VM con mayor frecuencia que su servidor jenkins.

En nuestras compilaciones de jenkins corbertura, solo usamos el plugin maven y parece funcionar bien sin problemas (pero, una vez más, no estamos usando Java 1.7, ni estamos usando Play).

El truco es usar un archivo de datos (cobertura.ser) por módulo para evitar bloqueos de tareas paralelas.

Con hormiga:

<cobertura-instrument todir="${build.dir}" datafile="cobertura.ser.${modulename}"> ...

Al final, combine los muchos archivos de cobertura en un solo archivo de cobertura:

<target name="merge-coverage"> <cobertura-merge datafile="cobertura.ser"> <fileset dir="${build.dir}"> <include name="cobertura.ser.*" /> </fileset> </cobertura-merge> </target>

Esto nos ha estado molestando por un tiempo (juego 1.2.4 / Jenkins). Existe un problema debido a la superposición de secuencias entre el plugin de jenkins cobertura (publicación de informes) y el módulo de cobertura de framework de juegos. Creo que es pura coincidencia de tiempo y, por tanto, intermitente. Tenemos el siguiente trabajo para la falta de una mejor resolución.

Se eliminó la acción de publicar informe de jenkins cobertura del trabajo de compilación principal. Creamos un nuevo trabajo de jenkins que está configurado con acción de informe de cobertura de cobertura de cobertura. En el nuevo trabajo, tenemos la acción de shell para copiar el coverage.xml del espacio de trabajo del trabajo de compilación principal en el espacio de trabajo del nuevo trabajo para que se ejecute la acción de publicación del informe de cobertura de coberturas. La copia (por razones obvias) se realiza para evitar ejecutar tanto cobertura de juego como cobertura de jenkins en el mismo trabajo.

No es el mejor, pero feliz de ver el informe de cobertura / gráficos :-)