Libelektra: Tâches de construction: certaines parties de la suite de tests échouent régulièrement

Créé le 25 févr. 2019  ·  14Commentaires  ·  Source: ElektraInitiative/libelektra

Description

J'ai ouvert cela comme un problème pour suivre tous les échecs de test temporaires dans l'un des travaux de construction. Les principales raisons des échecs de construction sont

. Dans un récent PR, j'ai dû redémarrer le travail de construction Jenkins 5 fois avant que tout fonctionne. Dans le PR après cela, j'ai redémarré le travail de construction Jenkins trois fois, pour autant que je me souvienne. Quoi qu'il en soit, le taux d'échec est beaucoup trop élevé à mon avis.

Les échecs

| Localisation | Tests échoués | Créer un emploi |
| ---------- | ------------- | ----------- |
| 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

Commentaire le plus utile

J'ai maintenant implémenté une nouvelle tentative automatique de ctest dans # 3224. Si vous rencontrez toujours des échecs temporaires des suites de tests, veuillez rouvrir le problème. (Nous pouvons augmenter le nombre d'essais.)

Pour les autres échecs de Jenkins / Docker, nous devons trouver d'autres solutions mais d'abord nous devons enfin faire la migration. Continuez donc à redémarrer le travail dans ces cas.

Tous les 14 commentaires

Merci pour votre résumé de ces problèmes!

Est-il possible de désactiver les tâches uniquement aux endroits où elles échouent?

Pour les plugins crypto et fcrypt @mpranj a souligné que gpg-agent peut échouer en cas de charge élevée du serveur. Peut-être pourrions-nous créer un travail de construction séparé pour les tests des plugins crypto et fcrypt ? Pour que d'autres développements ne soient pas bloqués.

Merci pour votre participation!

La séparation des travaux problématiques peut raccourcir les cycles de reconstruction. Mais je pense qu'il est clair que nous ne voulons pas du tout de reconstruction manuelle. Nous avons donc les options:

  • le rendant plus fiable
  • quelques boucles automatiques qui réessayent sur de telles erreurs
  • désactiver les tests (quand quelqu'un travaille sur ces pièces, elle doit les réactiver)

Qu'est-ce que tu penses?

  • le rendant plus fiable

difficilement possible tant que nous utilisons gpg-agent (ce qui est pénible dans les jobs batch)

  • quelques boucles automatiques qui réessayent sur de telles erreurs

Cela me semble sale.

  • désactiver les tests (quand quelqu'un travaille sur ces pièces, elle doit les réactiver)

Semble être l'option qui cause le moins d'inconfort, bien que des tests de régression manuels ne soient pas non plus une bonne chose.

Comme discuté lors de la réunion: nous devons désactiver les tests.

Alternative également discutée lors de la réunion: Utilisation de ctest --rerun-failed

L'exécution de ctest crée le fichier <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log (l'horodatage n'est utilisé qu'en mode Tableau de bord). Ce fichier est également utilisé par ctest --rerun-failed (voir Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f). Il contient simplement les numéros et les noms des derniers tests qui ont échoué.

Ma proposition serait d'appeler ctest comme avant. Si la sortie échoue, utilisez grep sur LastTestsFailed.log pour vérifier si l'un des tests listés ci-dessus a échoué. Et alors seulement, utilisez ctest --rerun-failed . Cela entraîne une sortie moins dupliquée / déroutante.

Mais si le problème est vraiment une charge élevée du serveur, cela n'aidera pas beaucoup. Au lieu de cela, nous pourrions essayer ctest --test-load . Cela devrait amener ctest à maintenir la charge du processeur sous un certain seuil.

IMO toujours la meilleure option serait de désactiver les tests et de créer un petit travail de construction qui installe uniquement les dépendances nécessaires à ces plugins / bibliothèques, ne compile que ce qui est nécessaire et n'exécute que les tests problématiques. De cette façon, nous pourrions probablement faire en sorte que l'exécution dure quelques minutes, auquel cas un redémarrage manuel serait acceptable, je pense. À titre de comparaison, nos travaux FreeBSD prennent actuellement environ 10 min (7 min de compilation, 2 min de test, 1 min autre) pour exécuter environ 200 tests.

PS. Je ne suis pas sûr de notre configuration, mais le redémarrage d'un pipeline jenkins à partir d'une certaine étape devrait être possible

Alternative également discutée lors de la réunion: Utilisation de ctest --rerun-failed

Merci d'avoir regardé dedans!

Mais si le problème est vraiment une charge élevée du serveur, cela n'aidera pas beaucoup. Au lieu de cela, nous pourrions essayer ctest --test-load.

@ingwinlu a beaucoup travaillé dans ce sens. Nos serveurs ont le débit le plus élevé avec une charge élevée. C'est-à-dire que nous ralentirions nos tests avec de telles options.

IMO toujours la meilleure option serait de désactiver les tests et de créer un petit travail de construction qui installe uniquement le

Les cas de test modulaires sont très difficiles à réaliser et à maintenir. @ingwinlu y a beaucoup travaillé. Je pense que nous ne pouvons pas refaire cet effort uniquement pour quelques tests peu fiables.

PS. Je ne suis pas sûr de notre configuration, mais le redémarrage d'un pipeline jenkins à partir d'une certaine étape devrait être possible

Ce serait génial. Mais je ne vois pas le bouton de redémarrage dans notre interface graphique. Avons-nous besoin d'un autre plugin ou d'une version plus récente? @ingwinlu a essayé d'ajouter "jenkins build * please" pour toutes les étapes du pipeline, malheureusement, cela n'a pas fonctionné.

Il semble que nous ayons encore des échecs (dbus voir # 2532)

Qu'en est-il d'exclure les cas de test dbus pour les versions Mac?

Il semble que nous ayons encore des échecs (dbus voir # 2532)

Oui.

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.

Avez-vous pu le reproduire localement?

Nous ne savons toujours pas pourquoi ce problème survient sporadiquement. Si vous avez une contribution, ce serait formidable.

Peut-être pouvons-nous simplement exclure les tests des travaux de construction problématiques? Ou est-ce que les tests dbus * échouent sur chaque tâche de construction où il s'exécute?

Avez-vous pu le reproduire localement?

Malheureusement non. Je suis sur Ubuntu.

Peut-être pouvons-nous simplement exclure les tests des travaux de construction problématiques? Ou est-ce que les tests dbus * échouent sur chaque tâche de construction où il s'exécute?

Je viens de redémarrer le travail de construction pour voir si cela se produit à nouveau.

Veuillez me réattribuer si nécessaire.

J'ai maintenant implémenté une nouvelle tentative automatique de ctest dans # 3224. Si vous rencontrez toujours des échecs temporaires des suites de tests, veuillez rouvrir le problème. (Nous pouvons augmenter le nombre d'essais.)

Pour les autres échecs de Jenkins / Docker, nous devons trouver d'autres solutions mais d'abord nous devons enfin faire la migration. Continuez donc à redémarrer le travail dans ces cas.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

markus2330 picture markus2330  ·  4Commentaires

sanssecours picture sanssecours  ·  4Commentaires

sanssecours picture sanssecours  ·  3Commentaires

mpranj picture mpranj  ·  3Commentaires

markus2330 picture markus2330  ·  3Commentaires