Ошибка теста 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 .

Сбой теста specload довольно явный:

Да, но неправильно ожидать, что двоичные файлы будут находиться в каталоге сборки после установки приложения. Бинарные файлы должны быть установлены и найдены либо в каталоге сборки, либо в каталоге установки.

Сбой теста specload довольно явный:

Да, но неправильно ожидать, что двоичные файлы будут находиться в каталоге сборки после установки приложения. Бинарные файлы должны быть установлены и найдены либо в каталоге сборки, либо в каталоге установки.

О, я пропустил, что ты установил Электру. Однако это не объясняет сбой quickdump , его тестовые данные установлены правильно.

Я тоже не знаю, как решить эту проблему. Конечно, мы можем установить исполняемые файлы тестовых приложений, но фактические исполняемые файлы тестов должны быть изменены во время установки, чтобы изменить место, где они ищут тестовое приложение.

Слишком много работы по поиску бинарных файлов (либо в сборке, либо в установленном каталоге), мы также можем исключить тесты из установки.

Мы могли бы просто использовать относительный путь и гарантировать, что он останется прежним во время установки, например, иметь оба двоичных файла в одном и том же каталоге.

Да, хорошая идея.

Более общим решением было бы наличие kdb <command> в каталоге сборки (в настоящее время работает, только если установлена ​​Elektra). Это было бы довольно трудоемко, так как KDB_EXEC_PATH поддерживает только один путь, но двоичные файлы разбросаны по разным частям каталога сборки.

у нас есть кдбдоступен также в каталоге сборки

Тесты можно легко выполнить с помощью ctest и/или make . Что касается других команд, большинство из них в любом случае имеют смысл только для установленной версии Elektra.

Мы могли бы просто использовать относительный путь и гарантировать, что он останется прежним во время установки, например, иметь оба двоичных файла в одном и том же каталоге.

Оказывается, это сложнее, чем ожидалось. stdlib будет рассматривать относительный путь как относительный к текущему рабочему каталогу, что бесполезно, и разрешение пути относительно текущего пути к исполняемому файлу невозможно независимым от платформы способом.

Таким образом, путь kdb <command> был бы весьма привлекательным.

Для установки достаточно установить его в TARGET_TOOL_EXEC_FOLDER

Только во время сборки нам нужно каким-то образом объединить build_dir/bin build_dir/scripts source_dir/scripts и текущие каталоги (возможно, и build+source).

@kodebach это все еще открыто? Можем ли мы многие обнаружить эту ситуацию и позволить тестам не запускаться в этой ситуации?

Или мы исправим это: KDB_EXEC_PATH теперь допускает несколько путей, поэтому мы можем добавлять любые нужные нам папки из каталога build/source. Затем вы просто позволяете kdb найти исполняемый файл.

Насколько я знаю, это все еще открыто, да.

У нас уже есть функция srcdir_file для тестов. Мы могли бы ввести аналогичный bindir_file . bindir по умолчанию будет равно ${CMAKE_INSTALL_PREFIX}/${TARGET_TOOL_EXEC_FOLDER} , но это будет какой-то способ переопределить его. CTest будет настроен (через CMake add_test ) таким образом, что для bindir будет установлено значение ${CMAKE_BINARY_DIR}/bin при использовании ctest .

И простое добавление биндира в KDB_EXEC_PATH и использование kdb <bin> не работает?

Нет, по нескольким причинам:

1. Это тесты testmod_ , они не должны полагаться на kdb .
2. Как тогда нам найти kdb ? Выполнение тестов с make run_all должно использовать не установленный kdb , а тот, что в ${CMAKE_BINARY_DIR}/bin .
3. KDB_EXEC_PATH по-прежнему будет содержать папку ${CMAKE_BINARY_DIR}/bin после установки kdb , что может вызвать различные проблемы.

Это тесты testmod_, они не должны полагаться на kdb.

Да, я согласен. Хорошо, если они работают автономно.

Как тогда нам найти kdb? Выполнение тестов с помощью make run_all не должно использовать установленный kdb, а тот, который находится в ${CMAKE_BINARY_DIR}/bin.

Тесты Shellrecorder уже используют kdb, и они работают как для установленной Elektra, так и из каталога сборки (даже если Elektra установлена).

KDB_EXEC_PATH по-прежнему будет содержать папку ${CMAKE_BINARY_DIR}/bin после установки kdb, что может вызвать различные проблемы.

Нет, KDB_EXEC_PATH не устанавливается для установленного kdb (если только его не задает пользователь)

Тесты 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_EXEC_PATH не устанавливается для установленного kdb (если только его не задает пользователь)

Я просто взял основную версию 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), остальная часть этой проблемы - только проблемы с упаковкой или что-то еще нужно реализовать?

Насколько я знаю, исходная проблема с specload все еще существует. TBH Я не уверен, почему у нас вообще есть возможность установить тесты testmod_ . Это не имеет никакого смысла. Это автономные тесты, которые тестируют один плагин изолированно. Если они действительно запускаются, их результаты будут одинаковыми, независимо от того, выполняются ли они в каталоге сборки или в каталоге установки.

TBH Я не уверен, почему у нас вообще есть возможность установить testmod_tests.

На данный момент у нас нет возможности отключить установку тестов, но мы можем сделать локальное переопределение, чтобы add_plugintest не устанавливал тесты (например, INSTALL_TESTING, но для отдельных add_plugintest ).

Это не имеет никакого смысла. Это автономные тесты, которые тестируют один плагин изолированно. Если они действительно запускаются, их результаты будут одинаковыми, независимо от того, выполняются ли они в каталоге сборки или в каталоге установки.

:wink:, есть много отличий, но большинство из них были связаны с самой системой плагинов (надеюсь, они все уже исправлены). Но, тем не менее, существует большое количество возможных проблем с зависимостями и проблем с установкой, поэтому запуск тестов testmod в установленном состоянии намного лучше, чем ничего не запускать. Но вы правы, что если есть тест shellrecorder, то тест testmod бесполезен.

• [X]Так для квикдампа понятно, тестмод тест ставить не надо.
• [ ] Для specload есть тест, но он кажется довольно минимальным, может быть, все в порядке, но лучше проверить еще раз.
• [ ] Для гоптов мы могли бы позволить запускать примеры программ в doc/tutorials/command-line-options.md?

@kodebach , можете ли вы проверить, можно ли безопасно исключить эти тесты?

@robaerd , вы можете исключить их в одном из ваших CI PR? (До или где вы добавляете тестирование пакетов.)

@markus2330 markus2330 У вас все еще возникает проблема с быстрым дампом? Насколько я знаю, мы так и не поняли, что там было не так. Я тоже не смог воспроизвести.

Информацию о 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
ммкс1:
Ключ 0x55a9efd438d0: dir:/tests/bench/__112, строка: gQHLlzB36CqIFlf, мета:/мета/_35: O6xNya6srhNhMFC, мета:/мета/_39: ublVuvyh1DgfOKU, мета:/мета/_58: 5Nyde2MHJODCBAT, мета:/мета/_79 ZK2xlaRMfobquxp, мета:/meta/_90: 0kCcc1pK7hOgY3F
Ключ 0x55a9efd44250: dir:/tests/bench/__114, строка: , meta:/binary:
Ключ 0x55a9efd441a0: dir:/tests/bench/__333, строка: SxTUAjM6OIpUV6s
Ключ 0x55a9efd440f0: dir:/tests/bench/__506, строка: cGqEvmXxUayNCf8
Ключ 0x55a9efd44040: dir:/tests/bench/__859, строка: rOI5aVFGlnjPLYJ
Ключ 0x55a9efd43f90: dir:/tests/bench/__863, строка: 8IBjbd5pzYBehrs
Ключ 0x55a9efd43f20: dir:/tests/bench/__868, строка: UVM0OPTf68yNXij
Ключ 0x55a9efd43d90: dir:/tests/bench/__911, строка: PgNbwPxfeqD30pH, мета:/meta/_35: O6xNya6srhNhMFC
ммкс2:
/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 в _IO_getc (fp=0x0) в getc.c:37

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

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

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

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

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

37 getc.c: Datei oder Verzeichnis nicht gefunden.
(гдб) бт

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

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

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

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

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

(gdb) бт полный

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

    result = <optimized out>

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

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() в /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 в main (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 (но с правами на запись в путь Электры). testmod_quickdump — единственный тест с такой проблемой.

но с правами на запись в путь Электры

Хорошо, это тоже работает, но в стандартной системе эти пути доступны только для root.

Я все еще думаю, что вся концепция запуска модульных тестов в установленной версии Elektra странна, а проблема с быстрым дампом — это чисто проблема с правами пользователя, а не ошибка, но я изменю путь в # 3618.

Я обновил код в #3618. Я также нашел аналогичный код в testmod_dump и изменил его. Понятия не имею, почему это не потерпело неудачу для вас. У testmod_xmltool может быть похожая проблема (хотя код другой, поэтому я его не менял).

testmod_quickdump был только одним из тех, которые использовали двоичные файлы и, следовательно, не использовали compare_line_files . Поэтому другие не будут segfault, но тесты все равно должны провалиться.

и проблема с быстрым дампом - это чисто проблема с правами пользователя, а не ошибка,

Это нарушение FHS, приложения не должны писать в /usr, он даже может быть доступен только для чтения.

Для записи мы должны использовать только временные файлы, а также очищать их после завершения тестов.