これらの問題の要約をありがとう！

失敗している場所でのみジョブを無効にすることは可能でしょうか？

cryptoおよびfcryptプラグインの場合、 @ mpranjは、サーバーの負荷が高い場合にgpg-agentが失敗する可能性があることを指摘しました。 たぶん、 cryptoとfcryptプラグインテスト用に別々のビルドジョブを作成できますか？ 他の開発が妨げられないように。

ご意見ありがとうございます！

問題のあるジョブを分離すると、再構築サイクルが短くなる可能性があります。 しかし、手動で再構築する必要がまったくないことは明らかだと思います。 したがって、オプションがあります。

• 信頼性を高める
• そのようなエラーを再試行するいくつかの自動ループ
• テストを無効にする（誰かがこれらの部分で作業するとき、彼女はそれらを再度アクティブにする必要があります）

どう思いますか？

• 信頼性を高める

gpg-agentを利用している限り、ほとんど不可能です（これはバッチジョブでは面倒です）

• そのようなエラーを再試行するいくつかの自動ループ

これは私には汚い感じがします。

• テストを無効にする（誰かがこれらの部分で作業するとき、彼女はそれらを再度アクティブにする必要があります）

手動の回帰テストを行うのも良いことではありませんが、不快感を最小限に抑えるオプションのようです。

会議で説明したように、テストを無効にする必要があります。

会議で議論された代替案： ctest --rerun-failed

ctestを実行すると、ファイル<cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log ctestが作成されます（タイムスタンプはダッシュボードモードでのみ使用されます）。 このファイルはctest --rerun-failedでも使用されます（Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060fを参照）。 最後に失敗したテストの番号と名前が含まれているだけです。

私の提案では、以前と同じようにctestを呼び出します。 終了に失敗した場合は、 grepでLastTestsFailed.logを使用して、上記のテストの1つが失敗したかどうかを確認します。 そして、その場合にのみctest --rerun-failedます。 これにより、出力の重複/混乱が少なくなります。

しかし、問題が本当にサーバーの負荷が高い場合は、あまり役に立ちません。 代わりに、 ctest --test-load試すことができます。 これにより、ctestはCPU負荷を特定のしきい値未満に保つ必要があります。

IMOは、テストを無効にして、これらのプラグイン/ライブラリに必要な依存関係のみをインストールし、必要なものだけをコンパイルし、問題のあるテストのみを実行する小さなビルドジョブを作成するのが依然として最善のオプションです。 そうすれば、ランタイムをおそらく数分で完了することができます。その場合、手動で再起動することは許容できると思います。 比較のために、FreeBSDジョブは現在約200のテストを実行するのに約10分（ビルド7分、テスト2分、その他1分）かかります。

PS。 セットアップについてはよくわかりませんが、特定の段階からjenkinsパイプラインを再起動できるはずです

会議で議論された代替案：ctestの使用--rerun-failed

ご覧いただきありがとうございます！

しかし、問題が本当にサーバーの負荷が高い場合は、あまり役に立ちません。 代わりに、ctest--test-loadを試すことができます。

@ingwinluはこの方向で多くの仕事をしました。 当社のサーバーは、高負荷で最高のスループットを発揮します。 つまり、そのようなオプションを使用すると、テストの速度が低下します。

IMOは依然として最良のオプションは、テストを無効にして、インストールするだけの小さなビルドジョブを作成することです。

モジュール式のテストケースは、達成および維持するのが非常に困難です。 @ingwinluはそれに多くの仕事をしました。 信頼性の低いいくつかのテストのためだけに、この努力を再び行うことはできないと思います。

PS。 セットアップについてはよくわかりませんが、特定の段階からjenkinsパイプラインを再起動できるはずです

それは素晴らしいことです。 しかし、GUIに再起動ボタンが表示されません。 別のプラグインまたは新しいバージョンが必要ですか？ @ingwinluは、すべてのパイプラインステップに「jenkinsbuild * please」を追加しようとしましたが、残念ながら機能しませんでした。

まだ失敗しているようです（dbusは＃2532を参照）

Macビルドのdbusテストケースを除外するのはどうですか？

まだ失敗しているようです（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 *テストケースは、実行されるすべてのビルドジョブで失敗しますか？

ビルドジョブを再開して、再度発生するかどうかを確認しました。

必要に応じて再割り当てしてください。

＃3224でctestの自動再試行を実装しました。 それでもテストスイートの一時的な障害が発生する場合は、問題を再度開いてください。 （試行回数を増やすことができます。）

Jenkins / Dockerの他の障害については、他の解決策を見つける必要がありますが、最初に最終的に移行を行う必要があります。 したがって、このような場合は引き続きジョブを再開してください。