Я открыл это как задачу, чтобы отслеживать все временные сбои тестов в одном из заданий сборки. Основные причины сбоев сборки:
. В недавнем 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
|
Спасибо за краткое изложение этих проблем!
Возможно ли отключать задания только там, где они не работают?
Для плагинов 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 нам нужно найти другие решения, но сначала нам нужно выполнить миграцию. Поэтому в таких случаях продолжайте перезапускать работу.
Самый полезный комментарий
Теперь я реализовал автоматическую повторную попытку ctest в # 3224. Если вы по-прежнему испытываете временные сбои при работе с тестовыми наборами, повторно откройте проблему. (Мы можем увеличить количество попыток.)
Для других сбоев Jenkins / Docker нам нужно найти другие решения, но сначала нам нужно выполнить миграцию. Поэтому в таких случаях продолжайте перезапускать работу.