¡Gracias por su resumen de estos problemas!

¿Es posible deshabilitar los trabajos solo en los lugares donde están fallando?

Para el complemento crypto y fcrypt @mpranj señaló que gpg-agent puede fallar en caso de alta carga del servidor. ¿Quizás podríamos crear un trabajo de compilación separado para las pruebas de los complementos crypto y fcrypt ? Para que no se bloqueen otros desarrollos.

¡Gracias por su aporte!

La separación de los trabajos problemáticos podría acortar los ciclos de reconstrucción. Pero creo que está claro que no queremos ninguna reconstrucción manual. Entonces tenemos las opciones:

• haciéndolo más confiable
• algunos bucles automáticos que vuelven a intentar estos errores
• deshabilitar las pruebas (cuando alguien trabaja en estas partes, necesita activarlas nuevamente)

¿Qué piensas?

• haciéndolo más confiable

difícilmente posible siempre que utilicemos gpg-agent (que es una molestia en los trabajos por lotes)

• algunos bucles automáticos que vuelven a intentar estos errores

Esto me parece sucio.

• deshabilitar las pruebas (cuando alguien trabaja en estas partes, necesita activarlas nuevamente)

Parece ser la opción que menos molestias causa, aunque tener pruebas de regresión manual tampoco es agradable.

Como se discutió en la reunión: debemos deshabilitar las pruebas.

Alternativa también discutida en la reunión: Usar ctest --rerun-failed

Al ejecutar ctest crea el archivo <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log (la marca de tiempo solo se usa en el modo Panel de control). Este archivo también lo utiliza ctest --rerun-failed (consulte Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f). Simplemente contiene los números y nombres de las últimas pruebas que fallaron.

Mi propuesta sería llamar ctest como antes. Si sale sin éxito, use grep en LastTestsFailed.log para verificar si una de las pruebas enumeradas anteriormente falló. Y solo entonces use ctest --rerun-failed . Esto provoca una salida menos duplicada / confusa.

Pero si el problema realmente es una alta carga del servidor, eso no ayudará mucho. En su lugar, podríamos probar ctest --test-load . Esto debería hacer que ctest mantenga la carga de la CPU por debajo de un cierto umbral.

En mi opinión, la mejor opción sería deshabilitar las pruebas y crear un pequeño trabajo de compilación que solo instale las dependencias necesarias para estos complementos / bibliotecas, solo compila lo necesario y solo ejecuta las pruebas problemáticas. De esa manera, podríamos lograr que el tiempo de ejecución se realice probablemente en unos pocos minutos, en cuyo caso el reinicio manual sería aceptable, creo. A modo de comparación, nuestros trabajos de FreeBSD actualmente tardan unos 10 minutos (7 minutos de construcción, 2 minutos de prueba, 1 minuto más) para ejecutar ~ 200 pruebas.

PD. No estoy seguro de nuestra configuración, pero debería ser posible reiniciar una canalización de jenkins desde una determinada etapa

Alternativa también discutida en la reunión: Usar ctest --rerun-failed

¡Gracias por investigarlo!

Pero si el problema realmente es una alta carga del servidor, eso no ayudará mucho. En su lugar, podríamos probar ctest --test-load.

@ingwinlu hizo mucho trabajo en esta dirección. Nuestros servidores tienen el mayor rendimiento con alta carga. Es decir, ralentizaríamos nuestras pruebas con esas opciones.

En mi opinión, la mejor opción sería deshabilitar las pruebas y crear un pequeño trabajo de compilación que solo instale el

Los casos de prueba modulares son muy difíciles de lograr y mantener. @ingwinlu se esforzó mucho. Creo que no podemos volver a hacer este esfuerzo solo para algunas pruebas poco fiables.

PD. No estoy seguro de nuestra configuración, pero debería ser posible reiniciar una canalización de jenkins desde una determinada etapa

Eso seria genial. Pero no veo el botón de reinicio en nuestra GUI. ¿Necesitamos otro complemento o una versión más reciente? @ingwinlu intentó agregar "jenkins build * please" para todos los pasos de la canalización, desafortunadamente, no funcionó.

Parece que todavía tenemos fallas (ver dbus # 2532)

¿Qué hay de excluir los casos de prueba de dbus para las compilaciones de Mac?

Parece que todavía tenemos fallas (ver dbus # 2532)

Sí.

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.

¿Pudiste reproducirlo localmente?

Aún no sabemos por qué este problema se produce de forma esporádica. Si tiene alguna aportación, sería genial.

¿Quizás simplemente podemos excluir las pruebas de los trabajos de construcción problemáticos? ¿O fallan los casos de prueba dbus * en cada trabajo de compilación en el que se ejecuta?

¿Pudiste reproducirlo localmente?

Lamentablemente no. Estoy en Ubuntu.

¿Quizás simplemente podemos excluir las pruebas de los trabajos de construcción problemáticos? ¿O fallan los casos de prueba dbus * en cada trabajo de compilación en el que se ejecuta?

Acabo de reiniciar el trabajo de compilación para ver si vuelve a suceder.

Por favor, vuelva a asignarme si es necesario.

Ahora implementé el reintento automático de ctest en # 3224. Si aún experimenta fallas temporales en las suites de prueba , vuelva a abrir el problema. (Podemos aumentar el número de intentos).

Para otras fallas de Jenkins / Docker, necesitamos encontrar otras soluciones, pero primero finalmente necesitamos hacer la migración. Por lo tanto, continúe reiniciando el trabajo en estos casos.