specload 테스트 실패는 매우 명시적입니다.

reason: : App '/home/jenkins/workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA/libelektra/obj-x86_64-linux-gnu/bin/elektra-specload-testapp' doesn't exist or is not executable

quickdump 의 경우 무엇이 잘못되었는지 정확히 말할 수는 없지만 elektraQuickdumpSet 어딘가에서 실패합니다. setKey 에 오류가 설정되어 있어야 하지만 기록되지 않은 것 같습니다(변경되어야 함).

gopts 가 실패하는 이유를 모르겠습니다. 오류 메시지가 인쇄되지 않았기 때문에 testapp elektra-gopts-testapp 을 실행할 수 없는 것 같습니다(오류 메시지가 인쇄되지 않는 유일한 경우). specload 오류와도 일치합니다.

스펙로드 테스트 실패는 매우 명시적입니다.

예, 하지만 애플리케이션이 설치된 후 빌드 디렉토리에 바이너리가 있을 것으로 예상하는 것은 잘못된 것입니다. 바이너리는 빌드 또는 설치 디렉토리에서 설치 및 검색되어야 합니다.

스펙로드 테스트 실패는 매우 명시적입니다.

예, 하지만 애플리케이션이 설치된 후 빌드 디렉토리에 바이너리가 있을 것으로 예상하는 것은 잘못된 것입니다. 바이너리는 빌드 또는 설치 디렉토리에서 설치 및 검색되어야 합니다.

아, Elektra를 설치하신 걸 놓쳤습니다. 그러나 이것이 quickdump 실패를 설명하는 것은 아니며 테스트 데이터가 올바르게 설치되었습니다.

또한 이 문제를 해결하는 방법을 잘 모르겠습니다. 물론 테스트 앱의 실행 파일을 설치할 수 있지만 실제 테스트 실행 파일은 테스트 앱을 찾는 위치를 변경하기 위해 설치 시간 동안 수정되어야 합니다.

바이너리(빌드 또는 설치된 디렉토리에서)를 검색하는 것은 너무 많은 작업이며, 설치에서 테스트를 제외할 수도 있습니다.

우리는 단순히 상대 경로를 사용하고 설치하는 동안 동일하게 유지되도록 할 수 있습니다. 예를 들어 동일한 디렉토리에 두 바이너리가 있습니다.

네, 좋은 생각입니다.

보다 일반적인 솔루션은 빌드 디렉토리에서도 kdb <command> 를 사용할 수 있는 경우입니다(현재 Elektra가 설치된 경우에만 작동함). KDB_EXEC_PATH는 하나의 경로만 지원하지만 바이너리는 빌드 디렉토리의 여러 다른 부분에 흩어져 있기 때문에 꽤 많은 작업이 될 것입니다.

우리는 kdb가 있습니다빌드 디렉토리에서도 사용 가능

테스트는 ctest 및/또는 make 를 통해 쉽게 실행할 수 있습니다. 다른 명령의 경우 대부분은 설치된 Elektra 버전에만 의미가 있습니다.

우리는 단순히 상대 경로를 사용하고 설치 중에 동일하게 유지되도록 할 수 있습니다. 예를 들어 동일한 디렉토리에 두 바이너리가 있습니다.

이것은 예상보다 어렵다는 것이 밝혀졌습니다. stdlib는 상대 경로를 현재 작업 디렉토리에 대한 상대 경로로 처리하므로 도움이 되지 않으며 현재 실행 파일의 경로를 기준으로 경로를 확인하는 것은 플랫폼 독립적인 방식으로 불가능합니다.

따라서 kdb <command> 방식은 상당히 매력적입니다.

설치를 위해서는 TARGET_TOOL_EXEC_FOLDER에 설치하면 됩니다.

빌드 시간 동안에만 build_dir/bin build_dir/scripts source_dir/scripts와 현재 디렉토리(둘 다 빌드+소스일 수도 있음)를 결합하는 방법이 필요합니다.

@kodebach 아직 열려 있습니까? 많은 사람들이 이 상황을 감지하고 이 상황에서 테스트가 실행되지 않도록 할 수 있습니까?

또는 수정합니다. 이제 KDB_EXEC_PATH가 다중 경로를 허용하므로 빌드/소스 디렉토리에서 필요한 모든 폴더를 추가할 수 있습니다. 그런 다음 실행 파일을 찾는 작업을 kdb 에 맡기기만 하면 됩니다.

AFAIK 이것은 아직 열려 있습니다. 예.

테스트를 위한 srcdir_file 함수가 이미 있습니다. 비슷한 bindir_file 를 소개할 수 있습니다. bindir 는 기본적으로 ${CMAKE_INSTALL_PREFIX}/${TARGET_TOOL_EXEC_FOLDER} 이지만 재정의하는 방법이 될 것입니다. CTest는 ctest $를 사용할 때 bindir 가 ${CMAKE_BINARY_DIR}/bin 로 설정되도록 (CMake의 add_test 를 통해) 설정됩니다.

그리고 단순히 bindir를 KDB_EXEC_PATH에 추가하고 kdb <bin> 를 사용하면 작동하지 않습니까?

아니요, 몇 가지 이유가 있습니다.

1. testmod_ 테스트이므로 kdb 에 의존해서는 안 됩니다.
2. 그러면 kdb 를 어떻게 찾을 수 있습니까? make run_all 로 테스트를 실행하면 설치된 kdb 가 아니라 ${CMAKE_BINARY_DIR}/bin 에 있는 것을 사용해야 합니다.
3. $#$ kdb 를 설치한 후에도 KDB_EXEC_PATH 에는 ${CMAKE_BINARY_DIR}/bin 폴더가 포함되어 있어 다른 문제가 발생할 수 있습니다.

이것은 testmod_ 테스트이며 kdb에 의존해서는 안됩니다.

그래, 난 동의. 독립 실행형으로 작동하면 좋습니다.

그러면 어떻게 kdb를 찾을 수 있을까요? make run_all로 테스트를 실행하면 설치된 kdb가 아니라 ${CMAKE_BINARY_DIR}/bin에 있는 kdb를 사용해야 합니다.

Shellrecorder 테스트는 이미 kdb를 사용하며 설치된 Elektra와 빌드 디렉토리(Elektra가 설치된 경우에도) 모두에서 작동합니다.

KDB_EXEC_PATH에는 kdb를 설치한 후에도 여전히 ${CMAKE_BINARY_DIR}/bin 폴더가 포함되어 있어 다른 문제가 발생할 수 있습니다.

아니요, 설치된 kdb에 대해 KDB_EXEC_PATH가 설정되지 않았습니다(사용자가 설정하지 않는 한)

Shellrecorder 테스트는 이미 kdb를 사용하며 설치된 Elektra와 빌드 디렉토리(Elektra가 설치된 경우에도) 모두에서 작동합니다.

쉘 테스트는 항상 "$KDB" 를 실행하고 kdb 는 실행하지 않기 때문에 작동합니다. 또한 make run_all 및 ctest 는 testscr_check_meta.sh 스크립트를 사용하는 반면 kdb 는 check_meta.sh 를 사용하기 때문입니다. 첫 번째에서 우리는 $KDB 를 ${CMAKE_BINARY_DIR}/bin/kdb 로 설정했고, 두 번째 것은 단순히 kdb 로 설정했습니다(따라서 $PATH 를 통해 해결됨).

아니요, 설치된 kdb에 대해 KDB_EXEC_PATH가 설정되지 않았습니다(사용자가 설정하지 않는 한)

방금 Elektra의 마스터 버전을 가져와 설치했습니다. /usr/local/lib/elektra/tool_exec/check_meta 파일에는 다음 줄이 포함되어 있습니다.

export KDB_EXEC_PATH="/home/klemens/libelektra/build/bin:$KDB_EXEC_PATH"

물론 이것은 testmod_* 테스트에는 영향을 미치지 않지만 그럼에도 불구하고 잘못된 것입니다. 새로운 문제를 만들겠습니다.

@petermax2 @kodebach 이 문제의 상태는 무엇입니까? 지금 #3246이 수정되었으므로(#3409를 통해) 이 문제의 나머지 부분은 패키징 문제뿐입니까 아니면 구현해야 할 사항이 남아 있습니까?

AFAIK specload 의 원래 문제는 여전히 존재합니다. TBH 왜 testmod_ 테스트를 설치해야 하는지 잘 모르겠습니다. 그것은 말도 안돼. 단일 플러그인을 격리하여 테스트하는 독립 실행형 테스트입니다. 실제로 실행하면 빌드 디렉토리에서 실행하든 설치 디렉토리에서 실행하든 결과는 동일합니다.

TBH 왜 testmod_ 테스트를 설치해야 하는지 잘 모르겠습니다.

현재로서는 테스트 설치를 비활성화하는 옵션이 없지만 add_plugintest 이 테스트를 설치하지 않도록 로컬 재정의를 만들 수 있습니다(INSTALL_TESTING과 같지만 개별 add_plugintest ).

그것은 말도 안돼. 단일 플러그인을 격리하여 테스트하는 독립 실행형 테스트입니다. 실제로 실행하면 빌드 디렉토리에서 실행하든 설치 디렉토리에서 실행하든 결과는 동일합니다.

:wink:, 많은 차이점이 있지만 대부분은 플러그인 시스템 자체와 관련이 있습니다(지금까지는 모두 수정되기를 바랍니다). 그러나 여전히 다양한 종속성 문제와 설치 문제가 있으므로 설치된 상태에서 testmod 테스트를 실행하는 것이 아무것도 실행하지 않는 것보다 훨씬 낫습니다. 그러나 쉘 레코더 테스트가 있으면 testmod 테스트가 쓸모가 없다는 것이 맞습니다.

• [X] 따라서 퀵덤프의 경우 testmod 테스트를 설치할 필요가 없습니다.
• [ ] 스펙로드의 경우 테스트가 있지만 아주 미미한 것 같습니다. 괜찮을 수도 있지만 다시 확인하는 것이 좋습니다.
• [ ] gopts의 경우 예제 프로그램이 doc/tutorials/command-line-options.md에서 실행되도록 할 수 있습니까?

@kodebach 이 테스트를 안전하게 제외할 수 있는지 확인할 수 있습니까?

@robaerd CI PR 중 하나에서 제외할 수 있습니까? (패키지 테스트를 추가하기 전이나 위치.)

@markus2330 퀵 덤프 문제가 계속 발생합니까? AFAIK 우리는 거기에서 무엇이 잘못되었는지 결코 알아내지 못했습니다. 저도 재현할 수 없었습니다.

gopts 및 specload에 대해서는 #3618을 참조하십시오.

예, 여전히 발생합니다.

kdb testmod_quickdump                                                                                                                                                                                                                    
QUICKDUMP     TESTS
==================

test varint
test basics
/home/jenkins/workspace/libelektra_master/libelektra/src/plugins/quickdump/testmod_quickdump.c:111: error in test_basics: call to kdbSet was not successful
zsh: segmentation fault (core dumped)  noglob kdb testmod_quickdump

또는 소스에서 호출할 때:

```퀵덤프 테스트

테스트 바린트
테스트 기본
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:92: test_basics의 오류: kdbGet 호출이 성공하지 못했습니다.
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93: test_basics의 오류: mmks2의 실제 크기는 0이었습니다.
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:93: test_basics의 오류: 키 세트 비교 실패, 키 세트의 크기가 크기(mmks1): 8, 크기(mmks2)와 동일하지 않습니다. 0
mmks1:
0x55a9efd438d0 키: dir:/tests/bench/__112, 문자열: gQHLlzB36CqIFlf, meta:/meta/_35: O6xNya6srhNhMFC, meta:/metaMHmeta/_39: ublVuvyh1DgfOKU/_5메타:/:2 ZK2xlaRMfobquxp, 메타:/메타/_90: 0kCcc1pK7hOgY3F
0x55a9efd44250 키: 디렉토리:/tests/bench/__114, 문자열: , 메타:/바이너리:
0x55a9efd441a0 키: 디렉토리:/tests/bench/__333, 문자열: SxTUAjM6OIpUV6s
0x55a9efd440f0 키: 디렉토리:/tests/bench/__506, 문자열: cGqEvmXxUayNCf8
0x55a9efd44040 키: 디렉토리:/tests/bench/__859, 문자열: rOI5aVFGlnjPLYJ
0x55a9efd43f90 키: 디렉토리:/tests/bench/__863, 문자열: 8IBjbd5pzYBehrs
0x55a9efd43f20 키: dir:/tests/bench/__868, 문자열: UVM0OPTf68yNXij
0x55a9efd43d90 키: 디렉토리:/tests/bench/__911, 문자열: PgNbwPxfeqD30pH, 메타:/메타/_35: O6xNya6srhNhMFC
mmks2:
/home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:111: test_basics의 오류: kdbSet에 대한 호출이 성공하지 못했습니다.
zsh: 분할 오류(코어 덤프됨) LD_LIBRARY_PATH=lib bin/testmod_quickdump

Stacktrace:

0 0x00007fa7c770ed74 in _IO_getc(fp=0x0) at getc.c:37

1 0x000055a9ede54c58 in compare_binary_files(filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0/test/test. )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31

2 test_basics() at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

3 /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278의 메인(argc=1, argv=0x7ffff28085f8)의 0x000055a9ede545d7

0 0x00007fa7c770ed74 in _IO_getc(fp=0x0) at getc.c:37

37 getc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt

0 0x00007fa7c770ed74 in _IO_getc(fp=0x0) at getc.c:37

1 0x000055a9ede54c58 in compare_binary_files(filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0/test/test. )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31

2 test_basics() at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

3 /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:278의 메인(argc=1, argv=0x7ffff28085f8)의 0x000055a9ede545d7

(gdb) bt 전체

0 0x00007fa7c770ed74 in _IO_getc(fp=0x0) at getc.c:37

    result = <optimized out>

1 0x000055a9ede54c58 in compare_binary_files(filename2=0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out", filename1=0x55a9efd429e0/test/test. )

at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:31
    f2 = 0x0
    c1 = <optimized out>
    f1 = 0x0
    result = 0
    c2 = <optimized out>
    f1 = <optimized out>
    f2 = <optimized out>
    result = <optimized out>
    c1 = <optimized out>
    c2 = <optimized out>
    end1 = <optimized out>
    end2 = <optimized out>

2 test_basics() at /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:113

    conf = <optimized out>
    modules = 0x55a9efd43a00
    setKey = 0x55a9efd42bb0
    errorKey = <optimized out>
    plugin = 0x55a9efd43b00
    ks = <optimized out>
    infile = 0x55a9efd429e0 "/usr/local/share/elektra/test_data/quickdump/test.quickdump"
    outfile = 0x55a9efd42a30 "/usr/local/share/elektra/test_data/quickdump/test.quickdump.out"
    __func__ = "test_basics"

3 0x000055a9ede545d7(argc=1, argv=0x7ffff28085f8) /home/markus/Projekte/Elektra/current/src/plugins/quickdump/testmod_quickdump.c:27

```

또는 소스에서 호출할 때:

테스트를 직접 실행할 때 ctest (예: ctest -R testmod_quickdump --ouptut-on-failure )를 사용하여 환경, 인수 등이 올바르게 설정되었는지 확인하십시오.

이 경우 LD_LIBRARY_PATH=lib bin/testmod_quickdump ../src/plugins/quickdump 가 필요하다고 생각합니다(예: gdb 로 디버그하려는 경우).

/usr/local/share/elektra/test_data/quickdump/test.quickdump 이 시스템에 존재하고 프로세스에 /usr/local/share/elektra/test_data/quickdump/test.quickdump.out 에 쓸 수 있는 권한이 있습니까? (아마도 sudo kdb testmod_quickdump 가 필요할 것 같습니다)

그렇다면 추가하십시오

output_error (setKey);
output_warnings (setKey);

testmod_quickdump.c:112 에 출력을 게시합니다.

elektraQuickdumpSet 가 실패했으므로 compare_binary_files 가 실패한다는 사실은 완전히 예상됩니다. (오류 메시지는 물론 더 나을 수 있고 segfault를 피할 수 있지만 _failed_ 테스트이므로 그다지 중요하지 않습니다)

네, 문제는 테스트 케이스가 적합하지 않은 폴더에 임시 파일을 생성하려고 한다는 것입니다. sudo kdb testmod_quickdump 는 문제 없이 실행됩니다. 따라서 "test_data/quickdump/test.quickdump.out"을 사용하는 대신 함수를 사용하여 임시 파일을 만드는 것으로 충분해야 합니다.

예라고 변경할 수 있지만 많은 테스트는 어쨌든 sudo 없이 실행되지 않으므로 실제로 문제로 보지 않습니다.

어떤 테스트를 말씀하시는 건가요? 나는 항상 sudo 없이 전체 제품군을 실행합니다(그러나 Elektra의 경로에 대한 쓰기 권한이 있음). testmod_quickdump는 해당 문제가 있는 유일한 테스트입니다.

그러나 Elektra의 경로에 대한 쓰기 권한이 있습니다.

물론 잘 작동하지만 표준 시스템에서 이러한 경로는 루트 액세스 전용입니다.

나는 여전히 설치된 Elektra 버전에서 단위 테스트를 실행하는 전체 개념이 이상하고 퀵 덤프 문제는 버그가 아니라 순전히 사용자 권한 문제라고 생각하지만 #3618에서 경로를 변경하겠습니다.

이제 #3618의 코드를 업데이트했습니다. 또한 testmod_dump 에서 유사한 코드를 발견하고 잘 변경했습니다. 왜 실패하지 않았는지 모릅니다. testmod_xmltool 비슷한 문제가 있을 수 있습니다(코드가 다르기 때문에 변경하지 않았지만).

testmod_quickdump 는 바이너리 파일을 사용하는 것 중 하나에 불과하므로 compare_line_files 를 사용하지 않았습니다. 따라서 다른 것들은 segfault가 아니지만 테스트는 여전히 실패해야 합니다.

그리고 퀵덤프 문제는 버그가 아니라 순전히 사용자 권한 문제입니다.

FHS 위반이며 응용 프로그램은 /usr에 쓸 수 없으며 읽기 전용일 수도 있습니다.

쓰기를 위해 임시 파일만 사용해야 하며 테스트가 완료된 후에도 정리해야 합니다.