Случилось снова https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/835/pipeline

WARNING: An illegal reflective access operation has occurred

WARNING: Illegal reflective access by com.google.inject.internal.cglib.core.$ReflectUtils$1 (file:/usr/share/maven/lib/guice.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)

WARNING: Please consider reporting this to the maintainers of com.google.inject.internal.cglib.core.$ReflectUtils$1

WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations

WARNING: All illegal access operations will be denied in a future release

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.6.0:compile (default-compile) on project libelektra4j: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.6.0:compile failed: Plugin org.apache.maven.plugins:maven-compiler-plugin:3.6.0 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-compiler-plugin:jar:3.6.0 -> org.apache.maven:maven-core:jar:3.0 -> org.apache.maven:maven-settings-builder:jar:3.0 -> org.sonatype.aether:aether-util:jar:1.7: Failed to read artifact descriptor for org.sonatype.aether:aether-util:jar:1.7: Could not transfer artifact org.sonatype.aether:aether-parent:pom:1.7 from/to central (https://repo.maven.apache.org/maven2): /home/jenkins/.m2/repository/org/sonatype/aether/aether-parent/1.7/aether-parent-1.7.pom.part (No such file or directory) -> [Help 1]

[ERROR] 

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR] 

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

make[2]: *** [src/bindings/jna/CMakeFiles/jna.dir/build.make:75: src/bindings/jna/libelektra4j/target/libelektra4j-0.9.0.jar] Error 1

make[1]: *** [CMakeFiles/Makefile2:17116: src/bindings/jna/CMakeFiles/jna.dir/all] Error 2

@Piankero Можете ли вы взглянуть на файлы maven?

Эта ошибка возникает случайным образом и не при каждой сборке?

Я мог бы только предложить обновить плагин maven-compiler-plugin с 3.6.0 до 3.8.1 и надеяться, что там доступна транзитивная зависимость сонара. Зависимость sonar 1.7 все равно устарела по годам (2010)

Да, это происходит случайно.

Нужна ли нам вообще зависимость от сонара?

Можем ли мы перейти на плагин maven-compiler-plugin 3.8.1 и по-прежнему поддерживать Apache Maven 3.3.9?

Нужна ли нам вообще зависимость от сонара?

Зависимость от сонара используется не нами напрямую, а maven-compiler-plugin .

Можем ли мы перейти на плагин maven-compiler-plugin 3.8.1 и по-прежнему поддерживать Apache Maven 3.3.9?

Версия maven и версия maven-compiler-plugin вообще не связаны. Вы должны быть в состоянии обновить его без проблем

Спасибо, не могли бы вы обновить версию?

Вроде апгрейд не помог, первый билд после слияния ПР уже провалился:

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/848/pipeline

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project libelektra4j: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed: Plugin org.apache.maven.plugins:maven-compiler-plugin:3.8.1 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-compiler-plugin:jarScanning dependencies of target elektra-lineendings-objects

:3.8.1 -> org.apache.maven:maven-core:jar:3.0 -> org.apache.maven:maven-settings-builder:jar:3.0 -> org.sonatype.aether:aether-impl:jar:1.7: Failed to read artifact descriptor for org.sonatype.aether:aether-impl:jar:1.7: Could not transfer artifact org.sonatype.aether:aether-parent:pom:1.7 from/to central (https://repo.maven.apache.org/maven2): /home/jenkins/.m2/repository/org/sonatype/aether/aether-parent/1.7/aether-parent-1.7.pom.part (No such file or directory) -> [Help 1]

[ERROR] 

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.

[ERROR] Re-run Maven using the -X switch to enable full debug logging.

[ERROR] 

[ERROR] For more information about the errors and possible solutions, please read the following articles:

[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException

Scanning dependencies of target elektra-logchange-objects

Scanning dependencies of target elektra-list-objects

Является ли сборка многопоточной? Это объяснило бы ошибку (https://jira.apache.org/jira/browse/MDEP-518)

Вы имеете в виду, если мы вызовем maven несколько раз одновременно? Это возможно.

Тогда, к сожалению, это открытая проблема maven .

Сборка Java очень проста, было бы стыдно не получить ее надежной. Может быть, мы просто забыли зависимость от уровня CMake (например, между testjna_maven и привязкой?).

Если это действительно внутренняя проблема в maven, в последнем посте проблемы maven описано решение, можете попробовать?

Если это действительно внутренняя проблема в maven, в последнем посте проблемы maven описано решение, можете попробовать?

В последнем посте описывается расширение, которое сильно меняет поведение maven с точки зрения управления банками. Мы просто получим еще одну зависимость в сборке, которая, вероятно, не очень стабильна. Также мы, вероятно, ограничим себя обновлением maven в будущем, потому что это изменяет поведение, подобное этому. Кроме того, в настоящее время у меня нет ресурсов для исправления каждого задания сборки с помощью этого

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

Более вероятно, что два процесса maven запускаются одновременно. Не должно быть слишком сложно избежать сборки JNI только в том случае, если JNA уже была построена.

2967 теперь содержит полный список проблем, я надеюсь, что мы скоро это исправим, чтобы одной проблемой стало меньше :+1:

произошло в https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/70/pipeline

Опять провалился в том же PR https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/74/pipeline

снова не удалось https://travis-ci.org/ElektraInitiative/libelektra/jobs/599129506

снова не удалось https://travis-ci.org/ElektraInitiative/libelektra/jobs/599129506

на самом деле эта работа по сборке вообще не потерпела неудачу

@sanssecours (или @Chemin1 ): как именно работает сборка jenkins в отношении кешей. Каждая сборка загружает образ докера и загружает все зависимости самого maven в контейнер? Или есть общая папка, которая используется всеми сборками для снижения нагрузки на диск/сеть?

Я не знаю ни о каком специальном коде для загрузки пакетов Maven на сервер сборки Jenkins. Я бы предположил, что cmake использует mvn для загрузки пакетов для сборки, как если бы вы собирали Elektra локально. Однако я не совсем знаком с настройкой Дженкинса.

Я бы предположил, что cmake использует mvn для загрузки пакетов для сборки.

mvn неявно загружает зависимости при сборке jna. Любая зависимость обычно загружается в локальный репозиторий .m2 по пути home . Выполняет ли jenkins какие-либо сборки/загрузки и т. д. в локально работающем контейнере Docker или использует стандартный временный каталог сборки из jenkins?

Выполняет ли jenkins какие-либо сборки/загрузки и т. д. в локально работающем контейнере Docker или использует стандартный временный каталог сборки из jenkins?

Я только знаю, что мы уже добавляем Google Test к большинству наших образов Docker. Например, вот соответствующий код для Debian Buster:

https://github.com/ElektraInitiative/libelektra/blob/990b866c70ebf42448f633b6f0c9d2bb36a85102/scripts/docker/debian/buster/Dockerfile#L87 -L94

.

Как именно работает сборка jenkins в отношении кешей. Каждая сборка загружает образ докера и загружает все зависимости самого maven в контейнер? Или есть общая папка, которая используется всеми сборками для снижения нагрузки на диск/сеть?

К сожалению, я не имею ни малейшего представления.

@Mistreated Вы знаете об этом больше?

Я просто запутался, как докер взаимодействует с каталогами jenkins. Проблема с этой проблемой возникает только в том случае, если несколько экземпляров maven пытаются загрузить в один и тот же каталог при разрешении зависимостей. Однако, если это делается через докер, этого не должно происходить, если одни и те же тома не смонтированы для всех образов докеров, которые включают каталог mvn. Это также объясняет, почему эта проблема возникает только на сервере jenkins, поскольку travis использует виртуальные машины, которые правильно инкапсулированы.

Эта строка предполагает, по крайней мере, что тома смонтированы, но я точно не знаю, как это делается на jenkins, поскольку $PWD может быть чем угодно.

Эта строка предполагает, по крайней мере, что тома смонтированы, но я точно не знаю, как это делается на jenkins, поскольку $PWD может быть чем угодно.

Я думаю, что это просто учебник, а не то, что на самом деле происходит с нашими Дженкинсами. Доступ к локальному зеркалу git — единственное монтирование, которое я вижу в нашем Jenkinsfile. Я не думаю, что есть какие-либо другие прямые взаимодействия с файловой системой хоста. Документы публикуются через SSH, а артефакты хранятся через archiveArtifacts . Мне кажется менее вероятным, что несколько экземпляров докеров обращаются к одному и тому же каталогу maven. Может быть, происходит что-то другое?

на самом деле эта работа по сборке вообще не потерпела неудачу

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

Как именно работает сборка jenkins в отношении кешей.

Это не имеет ничего общего с Дженкинсом, так как это также дает сбой локально и на Трэвисе.

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

Это шаг в правильном направлении.

Как уже было сказано, Elektra во время сборки выполняет как минимум два вызова mvn (jni и jna). Зависимость между ними, скорее всего, неверна, что приводит к параллельным выполнениям. Пожалуйста, расследуйте это.

Это не имеет ничего общего с Дженкинсом, так как это также дает сбой локально и на Трэвисе.

Ладно, мне это было непонятно.

Как уже было сказано, Elektra во время сборки выполняет как минимум два вызова mvn (jni и jna). Зависимость между ними, скорее всего, неверна, что приводит к параллельным выполнениям. Пожалуйста, расследуйте это.

Я открыл #3113

Посмотрим, повторится ли ошибка.

Вы видели эту ошибку снова? Вероятно, мы могли бы закрыть его и снова открыть, если сборка не удалась.

Больше я этого не видел. Так вроде исправили :100:

@markus2330 похоже, что это произошло сейчас на мастере. https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/master/35/pipeline

Вывод: log.txt

Это временный сбой, который мы можем игнорировать для выпуска?

Возможно, это не временно [0], но я думаю, что мы можем проигнорировать это для релиза.

[0] #3269 похоже был временным, потому что был какой-то "сброс соединения", но здесь я его не вижу и KDBTest.test_kdbGet_shouldPass:46 » Internal Sorry, module (null) issued error... очень похоже на то, что в KDB что-то было.

Сообщение об ошибке совершенно неверно, это проблема для @Piankero.

Я снова открываю, чтобы отслеживать эту новую проблему (в будущем лучше открывать новые проблемы, повторное использование проблем всегда несколько проблематично).

Извините, я не хотел повторно использовать вопросы. Я посмотрел на него и подумал, что это то же самое.

Не нужно извиняться, я был тем, кто использовал его повторно :wink:

Сообщение об ошибке совершенно неверно, это проблема для @Piankero.

К сожалению, я не могу воспроизвести эту ошибку, а также понятия не имею, как это может произойти на самом деле, потому что Elektra вернула -1 в привязку с «InternalError» (https://github.com/ElektraInitiative/libelektra/blob/09f2fdc2e33cf0ea0d20251f64c9485ccd7931c3/src/ bindings/jna/libelektra4j/src/main/java/org/libelektra/exception/mapper/ExceptionMapperService.java#L26-L29), но не может прочитать его через несколько строк https://github.com/ElektraInitiative/libelektra /blob/09f2fdc2e33cf0ea0d20251f64c9485ccd7931c3/src/bindings/jna/libelektra4j/src/main/java/org/libelektra/exception/KDBException.java#L54-L57

Как будто ключ с его метаданными был удален между ними. Эта ошибка повторилась между релизом и сейчас?

У вас есть объяснение, почему сообщение об ошибке так искажено?

Пожалуйста, добавьте модульный тест Java об ошибке, возникающей в Elektra (например, с плагином ошибок). Плагин ошибок также может быть полезен для учебника по ошибкам, который вы начали писать.

Пожалуйста, добавьте модульный тест Java об ошибке, возникающей в Elektra (например, с плагином ошибок). Плагин ошибок также может быть полезен для учебника по ошибкам, который вы начали писать.

Этот класс на самом деле проверяет каждое исключение с помощью плагина ошибок.

Это проверяет правильность извлечения метаданных.

У вас есть объяснение, почему сообщение об ошибке так искажено?

Что вы подразумеваете под "искаженным"? Вы имеете в виду точки в конце или что именно?

Этот класс на самом деле проверяет каждое исключение с помощью плагина ошибок.

Только в случае возникновения исключения, но не в том, какое сообщение оно отображает.

Это проверяет правильность извлечения метаданных.

Этот тест также не имеет ничего общего с ошибками, исходящими от Elektra.

Что вы подразумеваете под "искаженным"?

См. заголовок этого выпуска и log.txt :

Sorry, module (null) issued error (null):
(null)
Configfile: user/sw/tests/jna/1

    at org.libelektra.KDBTest.test_kdbGet_shouldPass(KDBTest.java:46)

Вы имеете в виду точки в конце или что именно?

Какую часть этого сообщения об ошибке вы считаете правильной? Также это полностью сломано:

Internal Sorry, module (null) issued error..

Какую часть этого сообщения об ошибке вы считаете правильной? Также это полностью сломано:

Это сообщение здесь является просто усеченным выводом maven в качестве сводки, и maven добавляет точки, чтобы указать, что впереди еще текст. Это будет сделано для всех неудачных тестов. Это не имеет ничего общего с реальным сообщением.

Этот тест также не имеет ничего общего с ошибками, исходящими от Elektra.

Это модульное тестирование правильного извлечения метаданных, и интеграционный тест для этого кажется излишним. Я могу добавить дополнительный интеграционный тест для разбора текста, но уверяю вас, что это не решит существующую проблему. Для меня это выглядит случайной ошибкой и с тех пор больше никогда не повторялось...

Это сообщение здесь является просто усеченным выводом maven в качестве сводки, и maven добавляет точки, чтобы указать, что впереди еще текст. Это будет сделано для всех неудачных тестов. Это не имеет ничего общего с реальным сообщением.

Итак, maven перетасовывает слова? Даже если это так, это не объясняет неработающее первое сообщение.

Это модульное тестирование правильного извлечения метаданных, и интеграционный тест для этого кажется излишним. Я могу добавить дополнительный интеграционный тест для разбора текста, но уверяю вас, что это не решит существующую проблему. Для меня это выглядит случайной ошибкой и с тех пор больше никогда не повторялось...

«Случайные ошибки» возникают только в том случае, если есть какие-то проблемы с тайм-аутом или программное обеспечение не работает. Я не вижу, где в этом случае может быть тайм-аут.

Но сначала сконцентрируйтесь на удивительном уроке.