Libelektra: 构建作业：部分测试套件经常失败

创建于 2019-02-25 · 14评论 · 资料来源: ElektraInitiative/libelektra

描述

我将其作为一个问题来解决，以跟踪其中一个构建作业中的所有临时测试失败。生成失败的主要原因是

通知绑定/插件的
加密插件的

。在最近的PR中，在一切正常之前，我不得不重新启动Jenkins构建作业5次。据我所记得，在那之后的

失败的

| 位置| 测试失败| 建立工作|
| ---------- | ------------- | ----------- |
| 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

资料来源

sanssecours

👍1

最有用的评论

我现在在＃3224中实现了ctest的自动重试。如果您仍然遇到测试套件的暂时故障，请重新打开该问题。（我们可以增加尝试的次数。）

对于Jenkins / Docker的其他失败，我们需要找到其他解决方案，但首先我们最终需要进行迁移。因此，在这种情况下，请继续重新启动作业。

markus2330 于 2019-11-17

🚀1 🎉1

所有14条评论

感谢您总结这些问题！

是否有可能仅在失败的地方禁用作业？

markus2330 于 2019-02-25

对于crypto和fcrypt插件@mpranj指出，如果服务器负载很高， gpg-agent可能会失败。也许我们可以为crypto和fcrypt插件测试创建一个单独的构建作业？这样其他发展就不会受到阻碍。

petermax2 于 2019-02-26

谢谢您的意见！

分开有问题的作业可能会使重建周期缩短。但是我认为很明显，我们根本不希望进行任何手动重建。因此，我们有以下选择：

使它更可靠
一些自动循环会重试此类错误
禁用测试（当某人在这些部件上工作时，她需要再次激活它们）

你有什么感想？

markus2330 于 2019-02-26

使它更可靠

只要我们利用gpg-agent几乎是不可能的（这在批处理作业中很痛苦）

一些自动循环会重试此类错误

我觉得这很脏。

禁用测试（当某人在这些部件上工作时，她需要再次激活它们）

似乎是造成最少不适的选择，尽管进行手动回归测试也不是一件好事。

petermax2 于 2019-02-27

正如会议中所讨论的：我们应该禁用测试。

markus2330 于 2019-02-27

👍1

会议中还讨论了替代方法：使用ctest --rerun-failed

运行ctest创建文件<cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log （时间戳仅在仪表板模式下使用）。 ctest --rerun-failed也使用此文件（请参阅Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f）。它仅包含上次失败的测试的编号和名称。

我的建议是像以前一样叫ctest 。如果退出失败，请在LastTestsFailed.log上使用grep LastTestsFailed.log来检查上面列出的测试之一是否失败。然后才使用ctest --rerun-failed 。这将导致较少的重复/混乱输出。

但是，如果问题确实出在服务器高负载上，那无济于事。相反，我们可以尝试ctest --test-load 。这将导致ctest将CPU负载保持在特定阈值以下。

IMO仍然最好的选择是禁用测试并创建一个小的构建作业，该作业仅安装这些插件/库所需的依赖项，仅编译必要的内容并仅运行有问题的测试。这样，我们就可以将运行时完成几分钟，在这种情况下，我认为手动重新启动是可以接受的。为了进行比较，我们的FreeBSD作业目前大约需要10分钟（构建7分钟，2分钟测试，其他1分钟）来运行〜200个测试。

PS。不确定我们的设置，但是应该可以从某个特定阶段重启jenkins管道

kodebach 于 2019-02-27

👍1

会议中还讨论了替代方法：使用ctest --rerun-failed

谢谢您的关注！

但是，如果问题确实出在服务器高负载上，那无济于事。相反，我们可以尝试ctest --test-load。

@ingwinlu在这个方向上做了很多工作。我们的服务器在高负载下具有最高的吞吐量。也就是说，使用此类选项会降低测试速度。

IMO仍然最好的选择是禁用测试并创建一个小的安装作业，仅安装

模块化测试用例很难实现和维护。 @ingwinlu投入了大量工作。我认为我们不能仅对一些不可靠的测试再次投入精力。

PS。不确定我们的设置，但是应该可以从某个特定阶段重启jenkins管道

那太好了。但是我在GUI中看不到重新启动按钮。我们需要其他插件还是更新版本？ @ingwinlu尝试为所有管道步骤添加“ jenkins build * please”，但不幸的是，它没有用。

markus2330 于 2019-02-28

似乎我们仍然有故障（dbus参见＃2532）

markus2330 于 2019-03-25

排除Mac构建的dbus测试用例怎么办？

markus2330 于 2019-06-10

👍1

似乎我们仍然有故障（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.

dominicjaeger 于 2019-08-19

您能够在本地复制它吗？

我们仍然不知道为什么这个问题偶尔发生。如果您有任何意见，那就太好了。

也许我们可以简单地从有问题的构建工作中排除测试？还是dbus *测试用例在运行它的每个构建作业上都失败了？

markus2330 于 2019-08-19

您能够在本地复制它吗？

不幸的是没有。我在Ubuntu上。

也许我们可以简单地从有问题的构建工作中排除测试？还是dbus *测试用例在运行它的每个构建作业上都失败了？

我只是重新启动了构建作业，以查看是否再次发生。

dominicjaeger 于 2019-08-19

👍1

如有必要，请重新分配我。

petermax2 于 2019-11-06

❤1