https://bugs.kde.org/show_bug.cgi?id=503969
--- Comment #7 from mcer...@redhat.com --- Created attachment 181372 --> https://bugs.kde.org/attachment.cgi?id=181372&action=edit proposed patch (In reply to Mark Wielaard from comment #6) > > > - LOGDIR is redefined to no longer use the valgrind-ltp-logs but a more > > > generic tests subdir > > > - The buildbot relies on the old name and so should be adjusted to deal > > > with "tests" > > > > My intent in this case was to align the structure of the logs with the one > > coming from my RHEL valgrind-ltp tester here: > > https://builder.sourceware.org/testruns/ > > ?op_mode=search_exact&has_keyvalue_k=testrun. > > gitdescribe&has_keyvalue_op=glob&has_keyvalue_v=*ltp* > > Aha, ok, so those have results in a top-level 'tests' dir. > But I think it makes sense to upload the results of both regtests and > ltpchecks together. > The buildbot script moves and renames the dir anyway. > We could move/rename it to ltp/tests ? Absolutely. Frank's suggestion: > ... > < fche> yes, that works. if OTOH the ltp tests are already structured into > subdirs that benefit from > preserving (for collision avoidance or whateve reasons), then N > subdirs are fine too > ... Taking into account Frank's suggestion to preserve the LTP testcase directory structure, I've renamed it to ltp/testcases. With the attached patch the structure looks like this: ... TESTING FINISHED, logs in /home/mcermak/WORK/valgrind/valgrind/auxprogs/auxchecks/ltp-full-20250130/ltp make[1]: Leaving directory '/home/mcermak/WORK/valgrind/valgrind/auxprogs' 41$ find . -type f -name '*.log' -o -name '*.trs' -o -name 'test-suite.log' | head ./testcases/kernel/syscalls/sched_get_priority_max/sched_get_priority_max01/sched_get_priority_max01.trs ./testcases/kernel/syscalls/sched_get_priority_max/sched_get_priority_max01/test-suite.log ./testcases/kernel/syscalls/sched_get_priority_max/sched_get_priority_max01/sched_get_priority_max01.log ./testcases/kernel/syscalls/sched_get_priority_max/sched_get_priority_max02/sched_get_priority_max02.trs ./testcases/kernel/syscalls/sched_get_priority_max/sched_get_priority_max02/test-suite.log ./testcases/kernel/syscalls/sched_get_priority_max/sched_get_priority_max02/sched_get_priority_max02.log ./testcases/kernel/syscalls/sigpending/sigpending02/sigpending02.log ./testcases/kernel/syscalls/sigpending/sigpending02/sigpending02.trs ./testcases/kernel/syscalls/sigpending/sigpending02/test-suite.log ./testcases/kernel/syscalls/renameat2/renameat201/renameat201.log 41$ > Could we put something inside the test-suite.log file? > So that people who find it know why it is there and where to find the actual > logs? > Maybe simply something like: > echo "See *.log files for details on each test in this directory." > > test-suite.log As I was attempting to preserve the LTP directory strucure, I've found that it can be done, BUT the test-suite.log needs to be present in every subdirectory containing .trs and .log files. Instead of putting the above message to it, I've put the test timing information to it. I thought this might be useful at some point. We can also add the info message you've suggested if you like it better. > One thing that is different from how the regtests do this is that they put a > test-suite.log file in each directory where there are test .log/.trs files? > Why is that necessary there and not here? Yeah, that appears to be needed so that bunsen can recognize and parse the logs. > The only unanswered question is whether the $exe.log file should be empty > when the test PASSes. > Don't we want some logs even if something passes? > > > Do you prefer to move generation of these .bunsen* files to the buildbot > > scripts? Done! :) I've generated new test data using the attached patch and uploaded those to bunsen: https://builder.sourceware.org/testrun/3036eba2de1cc44a1942f9681720ea234da9029e Please review the attached patch and let me know your thoughts. -- You are receiving this mail because: You are watching all bug changes.
