이러한 문제를 요약 해 주셔서 감사합니다!

작업이 실패한 곳에서만 작업을 비활성화 할 수 있습니까?

crypto 및 fcrypt 플러그인의 경우 @mpranj 는 높은 서버로드시 gpg-agent 가 실패 할 수 있다고 지적했습니다. crypto 및 fcrypt 플러그인 테스트를위한 별도의 빌드 작업을 만들 수 있을까요? 따라서 다른 개발이 차단되지 않습니다.

입력 해 주셔서 감사합니다!

문제가있는 작업을 분리하면 재 구축주기가 더 짧아 질 수 있습니다. 그러나 저는 우리가 어떤 수동 재 구축도 전혀 원하지 않는다는 것이 분명하다고 생각합니다. 따라서 다음과 같은 옵션이 있습니다.

• 더 신뢰할 수 있도록
• 이러한 오류에 대해 재 시도하는 일부 자동 루프
• 테스트 비활성화 (누군가이 부분에 대해 작업 할 때 다시 활성화해야 함)

어떻게 생각해?

• 더 신뢰할 수 있도록

gpg-agent (일괄 작업의 고통)을 활용하는 한 거의 불가능합니다.

• 이러한 오류에 대해 재 시도하는 일부 자동 루프

이것은 나에게 더럽다.

• 테스트 비활성화 (누군가이 부분에 대해 작업 할 때 다시 활성화해야 함)

수동 회귀 테스트를하는 것도 좋지 않지만 불편 함을 최소화하는 옵션 인 것 같습니다.

회의에서 논의한대로 : 테스트를 비활성화해야합니다.

회의에서도 논의 된 대안 : ctest --rerun-failed

ctest 를 실행하면 <cmake_build_dir>/Testing/Temporary/LastTestsFailed[_timestamp].log 파일이 생성됩니다 (타임 스탬프는 대시 보드 모드에서만 사용됨). 이 파일은 ctest --rerun-failed 에서도 사용됩니다 (Kitware / CMake @ eb2decc02d28f41a3e189d5387be24552c42060f 참조). 마지막으로 실패한 테스트의 번호와 이름 만 포함됩니다.

내 제안은 이전과 같이 ctest 를 호출 할 것입니다. 성공적으로 종료되지 않으면 grep 에서 LastTestsFailed.log 를 사용하여 위에 나열된 테스트 중 하나가 실패했는지 확인합니다. 그런 다음 ctest --rerun-failed . 이로 인해 중복 / 혼동 출력이 줄어 듭니다.

그러나 문제가 실제로 큰 도움이되지 않는 높은 서버 부하라면. 대신 ctest --test-load 시도해 볼 수 있습니다. 이로 인해 ctest는 CPU로드를 특정 임계 값 아래로 유지해야합니다.

IMO는 여전히 가장 좋은 옵션은 테스트를 비활성화하고 이러한 플러그인 / 라이브러리에 필요한 종속성 만 설치하고 필요한 것만 컴파일하고 문제가있는 테스트 만 실행하는 작은 빌드 작업을 만드는 것입니다. 그렇게하면 런타임을 몇 분 정도 완료 할 수 있습니다.이 경우 수동으로 다시 시작하는 것이 허용됩니다. 비교를 위해 FreeBSD 작업은 현재 약 200 개의 테스트를 실행하는 데 약 10 분 (빌드 7 분, 테스트 2 분, 기타 1 분)이 걸립니다.

추신. 설정에 대해 확실하지 않지만 특정 단계에서 젠킨스 파이프 라인을 다시 시작할 수 있습니다.

회의에서도 논의 된 대안 : ctest --rerun-failed 사용

조사해 주셔서 감사합니다!

그러나 문제가 실제로 큰 도움이되지 않는 높은 서버 부하라면. 대신 ctest --test-load를 시도 할 수 있습니다.

@ingwinlu 는이 방향으로 많은 작업을했습니다. 당사 서버는 높은 부하로 처리량이 가장 높습니다. 즉 우리는 그러한 옵션으로 테스트 속도를 늦출 것입니다.

IMO는 여전히 가장 좋은 방법은 테스트를 비활성화하고 다음 만 설치하는 작은 빌드 작업을 만드는 것입니다.

모듈 식 테스트 케이스는 달성하고 유지하기가 매우 어렵습니다. @ingwinlu 는 많은 작업을했습니다. 몇 가지 신뢰할 수없는 테스트에 대해서만 이러한 노력을 다시 할 수는 없다고 생각합니다.

추신. 설정에 대해 확실하지 않지만 특정 단계에서 젠킨스 파이프 라인을 다시 시작할 수 있습니다.

그것은 좋을 것입니다. 하지만 GUI에 다시 시작 버튼이 표시되지 않습니다. 다른 플러그인이나 최신 버전이 필요합니까? @ingwinlu 는 모든 파이프 라인 단계에 대해 "jenkins build * 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 * 테스트 케이스가 실행되는 모든 빌드 작업에서 실패합니까?

로컬에서 재현 할 수 있었습니까?

불행히도. 저는 우분투에 있습니다.

문제가있는 빌드 작업에서 테스트를 간단히 제외 할 수 있습니까? 아니면 dbus * 테스트 케이스가 실행되는 모든 빌드 작업에서 실패합니까?

방금 빌드 작업을 다시 시작하여 다시 발생하는지 확인했습니다.

필요한 경우 저를 다시 할당하십시오.

이제 # 3224에서 ctest의 자동 재 시도를 구현했습니다. 테스트 스위트 의 일시적인 오류가 계속 발생하면 문제를 다시여십시오. (시도 횟수를 늘릴 수 있습니다.)

Jenkins / Docker의 다른 실패에 대해서는 다른 솔루션을 찾아야하지만 먼저 마지막으로 마이그레이션을 수행해야합니다. 따라서 이러한 경우 계속해서 작업을 다시 시작하십시오.