Program Tip

Jenkins + Play 1.2.4 : cobertura 잠금 파일 / 보고서 관련 문제

programtip 2020. 11. 25. 08:23
반응형

Jenkins + Play 1.2.4 : cobertura 잠금 파일 / 보고서 관련 문제


Play 1.2.4 애플리케이션이 있고 애플리케이션 용 Jenkins (Ubuntu)가 있습니다. Cobertura에 문제가 있습니다.

테스트를 성공적으로 실행 한 후 때때로 다음과 같은 오류가 발생합니다.

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

이것은 "빌드를 망가 뜨리는 것"이 ​​아닌 것 같지만 빌드가 더 내려 가면 다음과 같은 결과가 나타납니다 (cobertura 보고서가 실패하게 함).

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

후속 빌드를 수동으로 실행하면 일반적으로 통과합니다.

cobertura 1.9.2의 Zero 코드 커버리지 에 따르면 테스트가 작동 중이며 자동 테스트 명령을 재생 한 후 -Dcobertura.use.java.nio = false 설정을 시도했습니다 .

이 오류가 때때로 발생했기 때문에 이것이 도움이되었는지 완전히 확신하지 못합니다. 하지만 그 후 플레이 자동 테스트 중단 문제가 발생했습니다.

  ...
  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>

완전히 결정적인 것이 없기 때문에 여기서 인과 관계에 대해 말하기는 약간 어렵습니다. (이것은 젠킨스 / 서버 재시작 후 하나 또는 두 개의 빌드 후에 발생하는 것으로 보입니다)

현재 우리 프로젝트에서 Cobertura를 비활성화하는 것을 고려하고 있지만 누군가 다른 아이디어가 있다면 그것은 좋을 것입니다 =)


분명히 이것은 JVM 구현 또는 cobertura JAR을 배포하는 방식의 JVM 잠금 문제로 인한 것입니다.

Jenkins는 많은 JVM 스레드를 생성 할 수 있으며 cobetura가 전역 클래스 경로에있는 경우 이상한 충돌이 발생할 수 있습니다.

나는 궁극적으로 이것이 cobertura의 사소한 버그로 인한 것이라고 가정합니다 (복잡한 corbertura 파일 잠금이 다른 더 중요한 문제를 해결하지 않는 한).

Cobertura의 FileLock (cobertura / src / main / java / net / sourceforge / cobertura / util / FileLocker.java)의 소스 코드에 따르면 여러 JVM이 Cobertura jar를로드하는 것과 관련된 몇 가지 문제가 있습니다.

해결하려면 Corbetura를 실행하고 사용하는 사본과 앱이 하나만 있는지 확인하십시오.

VM 구현이이를 수정 한 이유는 아마도 cobetrura가로드 될 수있는 방식에서 가변성의 양을 줄 였기 때문입니다. 또한 Jenkins 서버보다 더 높은 빈도로 VM을 다시 시작하고있을 수도 있습니다.

젠킨스 corbertura 빌드에서 우리는 maven 플러그인을 사용하고 이것은 문제없이 잘 작동하는 것 같습니다 (하지만 다시 우리는 Java 1.7을 사용하지 않으며 Play를 사용하지 않습니다).


This has been bothering us for a while (play 1.2.4/Jenkins). There is some problem due to overlapping sequences between jenkins cobertura plugin (report publish) and play framework cobertura module. I believe its purely timing coincidence and hence intermittent. We have the following work around for the lack of a better resolution.

Removed jenkins cobertura report publish action from the main build job. We created a new jenkins job that is setup with publish cobertura coverage report action. In the new job, we have the shell action to copy the coverage.xml from the main build job workspace to the workspace of the new job for cobertura coverage report publish action to run. The copy (for obvious reasons) is done to avoid running both play cobertura and jenkins cobertura in the same job.

Its not the best but happy to see the coverage report/graphs :-)


The trick is to use one datafile (cobertura.ser) per module to avoid locks from parallel tasks.

With ant:

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

At end merge the many cobertura files into one cobertura file:

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

-Dcobertura.use.java.nio=false the previous appears to require changing to true to be able to use file locking as your error message explained.

Also, somewhere the application probably requires adding the full folder classpath for cobertura.

It appears you are using something similar to a COF(constantly open file) , the error message is referring to a file that exists, but regions of the file are locked n the drive, not the file itself simply.


Did you set

%test.play.tmp=none

in your application.conf file ?

참고URL : https://stackoverflow.com/questions/12671642/jenkins-play-1-2-4-problems-with-cobertura-lock-files-report

반응형