Как исправить проблему несоответствия Cobertura Code Coverage для Java Project, который использует Gradle? - PullRequest
Новая
       36

Как исправить проблему несоответствия Cobertura Code Coverage для Java Project, который использует Gradle?

0 голосов
/ 15 мая 2019

Я использую плагин Cobertura Gradle для My Java Project для создания отчета о покрытии кода.Cobertura предоставлял непротиворечивые отчеты на моей машине с Windows, но когда я запускаю ту же сборку на сервере Jenkins и публикую отчет на SonarQube с помощью сонарного сканера, я вижу противоречивый отчет о покрытии.Каждая сборка давала разные проценты покрытия.Кобертура Версия: 2.1.1Версия плагина Cobertura Gradle: 'net.saliman: плагин gradle-cobertura: 2.3.2'Версия Java: 1.7Версия Gradle: 3.5

Я попытался отладить сборку gradle в информационном режиме и обнаружил исключение classNotFoundException при внедрении в журналы, поэтому я попытался добавить все зависимости вручную, используя параметр auxillaryClasspath для подключаемого модуля grabert cobertura, но безуспешно.

Файл Cobertura.gradle 

buildscript {
  repositories {
    maven { url 'http://central.maven.org/maven2/' }
    mavenLocal()
    dependencies.classpath 'org.apache.commons:commons-lang3:3.2',
                           'oro:oro:2.0.8',
                           'org.ow2.asm:asm:5.0.1',
                           'org.ow2.asm:asm-analysis:5.0.1',
                           'org.ow2.asm:asm-commons:5.0.1',
                           'org.ow2.asm:asm-tree:5.0.1',
                           'org.ow2.asm:asm-util:5.0.1',
                           'net.saliman:gradle-cobertura-plugin:2.3.2'
  }
}

apply plugin: net.saliman.gradle.plugin.cobertura.CoberturaPlugin

def jobpath = new File(buildDir.toString() + "/reports/cobertura")
cobertura {
  coverageFormats = ['html', 'xml']
  coverageReportDir = jobpath
}
test.finalizedBy(project.tasks.cobertura)

Основной build.gradle часть файла вставлена ​​сюда 

apply plugin: 'java'
apply from: 'cobertura.gradle'
...
...
test {
  forkEvery = 2
  maxParallelForks = 4
  maxHeapSize = "2048m"
  afterTest { TestDescriptor td, TestResult tr ->
    println "${tr} ${td}"
  }
}
....
...
dependencies{
...
..
}

Процент покрытия на машине с Windows составил 85% и соответствует, поэтому то же самое необходимо отразить и в отчете Jenkins Server..

1 Ответ

0 голосов
/ 21 мая 2019

Я попытался проанализировать логи cobertura, запустив сборку gradle с помощью команды "- info" и обнаружил, что во время внедрения cobertura писал 349 классов, но при генерации отчета он загружал случайное числоклассы.Но на моем компьютере с Windows он сохранял и загружал то же количество классов, то есть 349.

Журналы сборки на сервере Jenkins:
15:17:27 04:47:27.782 [INFO] [net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler] Cobertura: Saved information on 349 classes ...
15:18:14 04:48:14.326 [INFO] [net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler] Cobertura: Loaded information on 181 classes

Журналы сборки на ноутбуке с Windows:
14:30:25.745 [INFO] [net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler] Cobertura: Saved information on 349 classes ...
14:31:58.940 [INFO] [net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler] Cobertura: Loaded information on 349 classes.

Я проверил список проблем cobertura и обнаружил проблему параллелизмаво время записи файла cobertura.ser.https://github.com/cobertura/cobertura/issues/342

Обходной путь заключался в удалении parrellel вилок при выполнении тестовых случаев.

Поскольку мы использовали maxParallelForks = 4 в нашем основном build.gradle , параллельные исполнители повредили файл .ser.

Я удалил maxParallelForks = 4 из тестового задания, так как по умолчанию оно будет использовать 1, и сервер Jenkins начал предоставлять то же покрытие, что и на машине с Windows.

Наш сервер Jenkins - это мощная машина с многоядерными процессорами, и я думаю, именно поэтому параллельный форк работал над Jenkins и давал нам указанную выше проблему.

...