Vielen Dank für Ihre Zusammenfassung dieser Probleme!

Ist es möglicherweise möglich, die Jobs nur an den Stellen zu deaktivieren, an denen sie fehlschlagen?

Für das Plugin crypto und fcrypt @mpranj wurde darauf hingewiesen, dass gpg-agent bei hoher Serverlast fehlschlagen kann. Vielleicht könnten wir einen separaten Build-Job für die Plugin-Tests crypto und fcrypt erstellen? Damit andere Entwicklungen nicht blockiert werden.

Danke für deinen Beitrag!

Das Trennen der problematischen Jobs kann die Wiederherstellungszyklen verkürzen. Aber ich denke, es ist klar, dass wir überhaupt keine manuellen Umbauten wollen. Wir haben also die Möglichkeiten:

• macht es zuverlässiger
• Einige automatische Schleifen, die solche Fehler erneut versuchen
• Deaktivieren der Tests (wenn jemand an diesen Teilen arbeitet, muss er sie erneut aktivieren)

Was denkst du?

• macht es zuverlässiger

kaum möglich, solange wir gpg-agent (was bei Batch-Jobs schmerzhaft ist)

• Einige automatische Schleifen, die solche Fehler erneut versuchen

Das fühlt sich für mich schmutzig an.

• Deaktivieren der Tests (wenn jemand an diesen Teilen arbeitet, muss er sie erneut aktivieren)

Scheint die Option zu sein, die am wenigsten Unbehagen verursacht, obwohl manuelle Regressionstests auch nicht schön sind.

Wie in der Besprechung besprochen: Wir sollten die Tests deaktivieren.

Alternative, die auch in der Besprechung besprochen wurde: Verwenden von ctest --rerun-failed

Wenn Sie ctest ausführen, wird die Datei <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log (der Zeitstempel wird nur im Dashboard-Modus verwendet). Diese Datei wird auch von ctest --rerun-failed (siehe Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f). Es enthält einfach die Nummern und Namen der Tests, die zuletzt fehlgeschlagen sind.

Mein Vorschlag wäre, ctest wie zuvor anzurufen. Wenn das Beenden nicht erfolgreich ist, verwenden Sie grep für LastTestsFailed.log , um zu überprüfen, ob einer der oben aufgeführten Tests fehlgeschlagen ist. Und nur dann verwenden Sie ctest --rerun-failed . Dies führt zu weniger doppelten / verwirrenden Ausgaben.

Aber wenn das Problem wirklich eine hohe Serverlast ist, hilft das nicht viel. Stattdessen könnten wir ctest --test-load versuchen. Dies sollte dazu führen, dass ctest die CPU-Auslastung unter einem bestimmten Schwellenwert hält.

IMO ist immer noch die beste Option, die Tests zu deaktivieren und einen kleinen Build-Job zu erstellen, der nur die von diesen Plugins / Bibliotheken benötigten Abhängigkeiten installiert, nur das Notwendige kompiliert und nur die problematischen Tests ausführt. Auf diese Weise könnten wir die Laufzeit wahrscheinlich auf einige Minuten reduzieren. In diesem Fall wäre ein manueller Neustart meiner Meinung nach akzeptabel. Zum Vergleich: Unsere FreeBSD-Jobs benötigen derzeit etwa 10 Minuten (7 Minuten Build, 2 Minuten Test, 1 Minute Sonstiges), um ~ 200 Tests auszuführen.

PS. Wir sind uns über unser Setup nicht sicher, aber ein Neustart einer Jenkins-Pipeline ab einem bestimmten Stadium sollte möglich sein

Alternative, die auch in der Besprechung besprochen wurde: Verwenden von ctest --rerun-failed

Vielen Dank, dass Sie sich damit befasst haben!

Aber wenn das Problem wirklich eine hohe Serverlast ist, hilft das nicht viel. Stattdessen könnten wir ctest --test-load versuchen.

@ingwinlu hat viel in diese Richtung gearbeitet. Unsere Server haben den höchsten Durchsatz bei hoher Auslastung. Dh wir würden unsere Tests mit solchen Optionen verlangsamen.

IMO immer noch die beste Option wäre, die Tests zu deaktivieren und einen kleinen Build-Job zu erstellen, der nur die installiert

Modulare Testfälle sind sehr schwer zu erreichen und zu warten. @ingwinlu hat viel Arbeit

PS. Wir sind uns über unser Setup nicht sicher, aber ein Neustart einer Jenkins-Pipeline ab einem bestimmten Stadium sollte möglich sein

Das wäre toll. Aber ich sehe die Schaltfläche zum Neustart nicht in unserer GUI. Benötigen wir ein anderes Plugin oder eine neuere Version? @ingwinlu hat versucht, "Jenkins Build *

Es scheint, als hätten wir immer noch Fehler (dbus siehe # 2532)

Was ist mit dem Ausschluss der dbus-Testfälle für die Mac-Builds?

Es scheint, als hätten wir immer noch Fehler (dbus siehe # 2532)

Ja, machen wir.

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.

Konnten Sie es lokal reproduzieren?

Wir wissen immer noch nicht, warum dieses Problem sporadisch auftritt. Wenn Sie irgendwelche Eingaben haben, wäre es großartig.

Vielleicht können wir die Tests einfach von den problematischen Build-Jobs ausschließen? Oder schlagen die dbus * -Testfälle bei jedem Build-Job fehl, auf dem sie ausgeführt werden?

Konnten Sie es lokal reproduzieren?

Leider nicht. Ich bin auf Ubuntu.

Vielleicht können wir die Tests einfach von den problematischen Build-Jobs ausschließen? Oder schlagen die dbus * -Testfälle bei jedem Build-Job fehl, auf dem sie ausgeführt werden?

Ich habe gerade den Build-Job neu gestartet, um zu sehen, ob es wieder passiert.

Bitte weisen Sie mich bei Bedarf neu zu.

Ich habe jetzt die automatische Wiederholung von ctest in # 3224 implementiert. Wenn Sie noch temporäre Ausfälle der Testsuiten erleben bitte das Problem erneut öffnen. (Wir können die Anzahl der Versuche erhöhen.)

Für andere Fehler von Jenkins / Docker müssen wir andere Lösungen finden, aber zuerst müssen wir schließlich die Migration durchführen. Bitte starten Sie den Job in diesen Fällen weiter.