Jenkins + Play 1.2.4: проблемы с файлами блокировки cobertura / отчет

У нас есть приложение Play 1.2.4, и у нас есть Jenkins (на Ubuntu) для этого приложения. У нас проблемы с Кобертурой.

После успешного выполнения тестов время от времени мы получаем следующую ошибку:

---------------------------------------
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, но тесты работают, я попытался установить -Dcobertura.use.java.nio = false после play auto-test -command.

Поскольку эта ошибка возникала только время от времени, я не совсем уверен, помогло ли это. Но после этого у нас возникла проблема с зависанием автотеста игры:

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

Поскольку ничто не было полностью детерминированным, здесь немного сложно сказать о причинно-следственных связях. (Кажется, это происходит после одной или двух сборок после перезапуска jenkins / сервера)

В настоящее время я рассматриваю возможность отключения Cobertura в нашем проекте, но если у кого-то есть другие идеи, это было бы здорово =)


jenkins java cobertura playframework playframework-1.x
person Touko    schedule 01.10.2012    source источник
comment
У нас точно такая же проблема! Я тоже пробовал cobertura.use.java.nio таким же образом и он тоже зависает ...   -  person valanto    schedule 08.10.2012
comment
@valanto: какая у вас среда?   -  person Touko    schedule 08.10.2012
comment
такая же установка, как и вы, я думаю. Запуск jenkins на машине с Ubuntu. Используя play1.2.4, модуль cobertura 2.4, последнюю версию jenkins. мы запускаем автоматический тест воспроизведения также на jenkins, и когда я попробовал -Dcobertura.use.java.nio = false, он также завис. наши неудачи с cobertura тоже то и дело случаются ...   -  person valanto    schedule 08.10.2012
comment
Мне удалось преодолеть это, добавив виртуальную машину в качестве подчиненной к Jenkins. Мастер работает под управлением Ubuntu и не получает никаких заданий на сборку, подчиненный работает под управлением Centos и еще не показывает ошибку (около 300 сборок). Я понятия не имею, что начало вызывать ошибку, и иногда я получаю ее на своей рабочей станции Win7 (с тем же сообщением о ядре Linux: P)   -  person Leonidas K    schedule 16.10.2012
comment
@LeonidasK: Итак, похоже, что у Centos нет этой проблемы, которая возникает с Ubuntu (по крайней мере, пока)   -  person Touko    schedule 24.10.2012
comment
Я также могу подтвердить эту проблему, и я видел это в Mac OS X.   -  person Somatik    schedule 17.12.2012
comment
У меня такое впечатление, что кобертура бегает дважды. Я вижу ... Информация загружается ... дважды при каждом вызове плагина.   -  person Somatik    schedule 17.12.2012
comment
Попробуй поиграться с разрешениями. У меня была аналогичная проблема, связанная с разрешениями файла. Дженкинс не мог читать / записывать файл с помощью одной команды в сценарии сборки, но мог с помощью другой. Мы закончили chmod 777 -R ~jenkins на нашей машине, ха-ха.   -  person reagan    schedule 23.06.2013

Ответы (5)


arrow_upward
2
arrow_downward

Очевидно, это связано с проблемами блокировки JVM либо в вашей реализации JVM, либо, скорее, в том, как вы развертываете свой cobertura JAR.

Дженкинс может порождать множество потоков JVM, и если cobetura находится на вашем глобальном пути к классам, возможно, что происходят какие-то странные коллизии.

Я предполагаю, что, в конечном счете, это следует отнести к незначительной ошибке в cobertura (если только сложная блокировка файлов corbertura не решает какую-либо другую более важную проблему).

Согласно исходному коду для Cobertura FileLock (cobertura / src / main / java / net / sourceforge / cobertura / util / FileLocker.java), есть некоторые проблемы, связанные с загрузкой нескольких JVM jar-файлов Cobertura.

Чтобы решить эту проблему, убедитесь, что есть только одна копия и одно приложение, запускающее и использующее Corbetura.

Причина, по которой ваша реализация виртуальной машины исправила это, скорее всего, заключается в том, что вы уменьшили степень изменчивости в способе загрузки cobetrura. Также, возможно, вы перезагружаете свою виртуальную машину с большей частотой, чем ваш сервер jenkins.

В наших сборках jenkins corbertura мы просто используем плагин maven, и он, кажется, работает нормально без проблем (но опять же, мы не используем java 1.7 и не используем Play).

person jayunit100    schedule 07.07.2013

arrow_upward
2
arrow_downward

Это нас уже давно беспокоит (играйте в 1.2.4 / Jenkins). Существует некоторая проблема из-за перекрытия последовательностей между плагином jenkins cobertura (публикация отчета) и модулем cobertura play framework. Я считаю, что это чисто временное совпадение и, следовательно, прерывистое. У нас есть следующий обходной путь из-за отсутствия лучшего разрешения.

Удалено действие публикации отчета jenkins cobertura из основного задания сборки. Мы создали новую вакансию jenkins, в которой настроено действие публикации отчета о покрытии cobertura. В новом задании у нас есть действие оболочки для копирования файла extension.xml из основной рабочей области задания сборки в рабочую область нового задания для выполнения действия публикации отчета о покрытии cobertura. Копия (по понятным причинам) сделана, чтобы не запускать play cobertura и jenkins cobertura в одном задании.

Это не самое лучшее, но приятно видеть отчет / графики покрытия :-)

person bobbypavan    schedule 29.07.2013

arrow_upward
2
arrow_downward

Уловка состоит в том, чтобы использовать один файл данных (cobertura.ser) для каждого модуля, чтобы избежать блокировок от параллельных задач.

С муравьем:

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

В конце слейте множество файлов cobertura в один файл cobertura:

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

arrow_upward
1
arrow_downward

-Dcobertura.use.java.nio = false предыдущее, похоже, требует изменения на true, чтобы иметь возможность использовать блокировку файлов, как объясняется в сообщении об ошибке.

Кроме того, где-то приложение, вероятно, требует добавления полного пути к классам папки для cobertura.

похоже, вы используете что-то похожее в COF (постоянно открытый файл) сообщение об ошибке относится к файлу, который существует, но области файла заблокированы на диске, а не просто сам файл.

person nicephotog    schedule 25.07.2013

arrow_upward
0
arrow_downward

Вы установили

%test.play.tmp=none

в вашем файле application.conf?

person Seb Cesbron    schedule 28.06.2013
comment
Это следует сформулировать как ответ, а не как вопрос. - person jayunit100; 07.07.2013