Libelektra: Сборка заданий: части Test Suite регулярно выходят из строя

Созданный на 25 февр. 2019  ·  14Комментарии  ·  Источник: ElektraInitiative/libelektra

Описание

Я открыл это как задачу, чтобы отслеживать все временные сбои тестов в одном из заданий сборки. Основные причины сбоев сборки:

. В недавнем PR мне пришлось перезапустить задание сборки Jenkins 5 раз, прежде чем все заработало. В PR после этого я трижды перезапускал задание Jenkins build, насколько я помню. В любом случае, на мой взгляд, процент отказов слишком высок.

Неудачи

| Расположение | Неудачные тесты | Строить работу |
| ---------- | ------------- | ----------- |
| master | testmod_gpgme (1) | debian-stable-full |
| master | testmod_gpgme (1), testmod_zeromqsend (1) | debian-stable-full-ini |
| master | testmod_crypto_botan (1), testmod_fcrypt (1), testmod_gpgme (2), testmod_zeromqsend (1) | debian-stable-full-mmap |
| master | testmod_crypto_botan (1), testmod_fcrypt (2) | debian-unstable-full |
| master | testmod_crypto_botan (2), testmod_crypto_openssl (3), testmod_fcrypt (1) | debian-unstable-full-clang |
| PR #2442 | testmod_crypto_openssl (1), testmod_gpgme (1) | debian-stable-full-ini |
| PR #2442 | testmod_crypto_openssl (1), testmod_crypto_botan (1), testmod_fcrypt (1), testmod_gpgme (3) | debian-stable-full-mmap |
| PR #2442 | testmod_crypto_openssl (1), testmod_fcrypt (1) | debian-unstable-full |
| PR #2442 | testmod_crypto_openssl (1), testmod_crypto_botan (1), testmod_fcrypt (1) | debian-unstable-full-clang |
| PR #2442 | testmod_dbus (1), testmod_dbusrecv (1) | 🍎 MMap |
| PR #2443 | testmod_crypto_botan (1), testmod_fcrypt (1) | debian-unstable-full |
| PR #2443 | testmod_crypto_openssl (1), testmod_crypto_botan (1) | debian-unstable-full-clang |
| PR #2443 | testmod_dbus (1), testmod_dbusrecv (1) | 🍎 MMap |
| PR #2445 | testmod_crypto_openssl (1), testmod_crypto_botan (1), testmod_fcrypt (1) | debian-stable-full-ini |
| PR #2445 | testmod_crypto_openssl (2), testmod_crypto_botan (2), testmod_fcrypt (2), testmod_gpgme (1) | debian-stable-full-mmap |
| PR #2445 | testmod_crypto_openssl (2), testmod_fcrypt (2) | debian-unstable-full |
| PR #2445 | testmod_dbus (1), testmod_dbusrecv (1) | 🍏 GCC |

bug build

Самый полезный комментарий

Теперь я реализовал автоматическую повторную попытку ctest в # 3224. Если вы по-прежнему испытываете временные сбои при работе с тестовыми наборами, повторно откройте проблему. (Мы можем увеличить количество попыток.)

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

Все 14 Комментарий

Спасибо за краткое изложение этих проблем!

Возможно ли отключать задания только там, где они не работают?

Для плагинов crypto и fcrypt @mpranj указал, что gpg-agent может выйти из строя в случае высокой нагрузки на сервер. Может быть, мы могли бы создать отдельное задание на сборку для тестов плагинов crypto и fcrypt ? Чтобы другие разработки не блокировались.

Спасибо за ваш вклад!

Разделение проблемных заданий может сократить циклы восстановления. Но я думаю, что ясно, что мы вообще не хотим никаких ручных перестроек. Итак, у нас есть варианты:

  • делая его более надежным
  • несколько автоматических циклов, которые повторяют такие ошибки
  • отключение тестов (когда кто-то работает с этими частями, ему нужно снова их активировать)

Что вы думаете?

  • делая его более надежным

вряд ли возможно, пока мы используем gpg-agent (что затрудняет пакетные задания)

  • несколько автоматических циклов, которые повторяют такие ошибки

Мне это кажется грязным.

  • отключение тестов (когда кто-то работает с этими частями, ему нужно снова их активировать)

Кажется, это вариант, который вызывает наименьший дискомфорт, хотя ручные регрессионные тесты тоже нехорошо.

Как обсуждалось на встрече: мы должны отключить тесты.

Альтернатива также обсуждалась на встрече: Использование ctest --rerun-failed

Запуск ctest создает файл <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log (метка времени используется только в режиме панели инструментов). Этот файл также используется ctest --rerun-failed (см. Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f). Он просто содержит номера и названия последних неудачных тестов.

Мое предложение ctest как и раньше называть grep на LastTestsFailed.log чтобы проверить, не завершился ли один из перечисленных выше тестов. И только потом используйте ctest --rerun-failed . Это приводит к меньшему дублированию / путанице в выводе.

Но если проблема действительно в высокой загрузке сервера, это не сильно поможет. Вместо этого мы могли бы попробовать ctest --test-load . Это должно привести к тому, что ctest будет поддерживать загрузку процессора ниже определенного порога.

ИМО по-прежнему лучшим вариантом было бы отключить тесты и создать небольшое задание сборки, которое устанавливает только зависимости, необходимые для этих плагинов / библиотек, компилирует только то, что необходимо, и запускает только проблемные тесты. Таким образом, мы могли бы сократить время выполнения до нескольких минут, и в этом случае ручной перезапуск, я думаю, будет приемлемым. Для сравнения, наши задания FreeBSD в настоящее время занимают около 10 минут (7 минут на сборку, 2 минуты на тестирование, 1 минуту другое) на выполнение ~ 200 тестов.

PS. Не уверен в нашей настройке, но перезапуск конвейера Дженкинса с определенного этапа должен быть возможен

Альтернатива также обсуждалась на встрече: Использование ctest --rerun-failed

Спасибо, что изучили это!

Но если проблема действительно в высокой загрузке сервера, это не сильно поможет. Вместо этого мы могли бы попробовать ctest --test-load.

@ingwinlu проделал большую работу в этом направлении. Наши серверы имеют самую высокую пропускную способность при высокой нагрузке. Т.е. с такими опциями мы бы замедлили наши тесты.

ИМО по-прежнему лучшим вариантом было бы отключить тесты и создать небольшое задание по сборке, которое устанавливает только

Модульные тестовые примеры очень сложно создать и поддерживать. @ingwinlu вложил в это много

PS. Не уверен в нашей настройке, но перезапуск конвейера Дженкинса с определенного этапа должен быть возможен

Это было бы прекрасно. Но я не вижу кнопки перезагрузки в нашем графическом интерфейсе. Нужен ли нам другой плагин или более новая версия? @ingwinlu попытался добавить «jenkins build * please» для всех этапов конвейера, к сожалению, это не сработало.

Похоже, у нас все еще есть сбои (dbus см. # 2532)

Как насчет исключения тестовых случаев dbus для сборок Mac?

Похоже, у нас все еще есть сбои (dbus см. # 2532)

Да.

gcc --version

Configured with: --prefix=/Applications/Xcode-10.2.1.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode-10.2.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1

Apple LLVM version 10.0.1 (clang-1001.0.46.4)

Target: x86_64-apple-darwin18.5.0

Thread model: posix

InstalledDir: /Applications/Xcode-10.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

(...)

DBUSRECV TESTS

==============

testing prerequisites

detecting available bus types - please ignore single error messages prefixed with "connect:"

connect: Failed to open connection to system message bus: Failed to connect to socket /usr/local/var/run/dbus/system_bus_socket: No such file or directory

test commit

test adding keys

../src/plugins/dbusrecv/testmod_dbusrecv.c:228: error in test_keyAdded: string "system/tests/testmod_dbusrecv/added" is not equal to "user/tests/foo/bar"

    compared: expectedKeyName and keyName (test_callbackKey)

test adding keys

testmod_dbusrecv Results: 34 Tests done — 1 error.

Удалось ли вам воспроизвести его локально?

Мы до сих пор не знаем, почему эта проблема возникает спорадически. Если у вас есть какой-либо вклад, это было бы здорово.

Может быть, мы можем просто исключить тесты из проблемных заданий сборки? Или тесты dbus * терпят неудачу при каждом задании сборки, где он выполняется?

Удалось ли вам воспроизвести его локально?

К сожалению нет. Я на Ubuntu.

Может быть, мы можем просто исключить тесты из проблемных заданий сборки? Или тесты dbus * терпят неудачу при каждом задании сборки, где он выполняется?

Я только что перезапустил сборку, чтобы посмотреть, повторится ли это снова.

Пожалуйста, назначьте меня повторно, если необходимо.

Теперь я реализовал автоматическую повторную попытку ctest в # 3224. Если вы по-прежнему испытываете временные сбои при работе с тестовыми наборами, повторно откройте проблему. (Мы можем увеличить количество попыток.)

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

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

sanssecours picture sanssecours  ·  4Комментарии

markus2330 picture markus2330  ·  4Комментарии

mpranj picture mpranj  ·  4Комментарии

markus2330 picture markus2330  ·  3Комментарии

mpranj picture mpranj  ·  3Комментарии