Test path.t failure

[jouvin]

On my SL6 development machine, path.t fails:

# VERBOSE FAIL: Unsupported LC::Check function no_lc_check_function
# DEBUG: 1 Ignoring/resetting previous existing fail: Unsupported LC::Check function no_lc_check_function
# DEBUG: 1 Ignoring/resetting previous existing error: *** : origexception LC_Check unknown dispatch
No root path(s) specified
 at src/test/perl/path.t line 269

#   Failed test 'directory_exists false on missing directory'
#   at src/test/perl/path.t line 270.

#   Failed test 'any_exists false on missing directory'
#   at src/test/perl/path.t line 272.
# DEBUG: 1 Ignoring/resetting previous existing fail: origfailure existence tests
# DEBUG: 1 Ignoring/resetting previous existing error: *** : origexception existence tests

Do I have something missing? Not sure why the test succeeded on GitHub...

[stdweird]

tests pass with blank EL6 VM and build_all_repos. can you mail me the whole output of

QUATTOR_TEST_LOG_CMD_MISSING=1 QUATTOR_TEST_LOG_CMD=1 QUATTOR_TEST_LOG_DEBUGLEVEL=3 mvn clean test -Dunitttest=path.t
find target

[jrha]

Please don't assign milestones to issues unless they are release blocking issues (no evidence for this one yet) or they have an associated PR.

[jouvin]

@stdweird here is the log: log.txt

[jouvin]

@jrha I apologize it I did something wrong... Nevertheless, I always tend to assign a milestone to issue as I am afraid that an issue without a milestone will never be looked at. I could have put 16.6 but in this case decided 16.4 because I always find a problem in a test suspect and it may be the sign of something that will popup in the release process later... I may have been wrong....

[stdweird]

@jouvin the attached log has all tests passing. can you try to reproduce a failing one?

[jrha]

@jouvin no worries, we decided to keep a global backlog of unassigned issues and monitor it to prevent issues being lost rather than losing them while they are assigned to future releases. Neither system is perfect.

[jouvin]

@stdweird problem understood (sorry I awa in a meeting and didn't check that the log reproduced the error). It happens if you don't clean. Certainly nothing urgent then. But for me, it is a bad practice if we always need to run the clean phase... New log with the problem:
log2.txt

[stdweird]

euhm, i never run without clean 😄

[jrha]

I'm now seeing this on a clean SL6.7 VM while trying to build_all_repos

[stdweird]

@jrha can you pm me the gzipped output?

[jrha]

Sure, I'm just re-running to confirm.

[stdweird]

i ran build_all_repos on el65, el71 and el59 and all went ok

[jrha]

FWIW I also initially saw the failure to install perl-enum as well, so they may be something deeper wrong with the VM images.

[jrha]

@stdweird I've emailed the build_all_repos output to you.

[stdweird]

are you running the tests as root? if so, can you run the tests via https://github.com/quattor/release/blob/master/src/scripts/context_init_build_all_repos.sh

the tests fail on a premission restricted piece of code, but if root is allowed to ignore directory permissions, the tests can trigger the expected failure.

[jrha]

I am, always have. I'm lazy and it's highlighted some non-mocked code in the past.
I'll try running again as a non-root user.

[stdweird]

ok, i'll try to run th etests as root, and see if it is an root related issue or not.

[jrha]

Ok it passes fine as a unprivileged user, now dying on rpmlint, so new issue.

[jouvin]

Hit that problem again... Log file CAF_path_test.log.gz attached.

[stdweird]

@jouvin thanks for the log. what filesystem is this? and you are running as non-root, right?
if you are runnign the tests to get rpms, you can get them from jenkins too https://jenkins1.ugent.be/view/Quattor/job/perl-CAF/lastBuild/org.quattor.client.libraries$perl-CAF/artifact/org.quattor.client.libraries/perl-CAF/16.12.1-SNAPSHOT/perl-CAF-16.12.1-SNAPSHOT.rpm

[jouvin]

Yes I am running non root... but I run tests to assess that I broke nothing, not to get RPMs! Thus my problem if I cannot run the tests reliably on my local SL6 machine...

[stdweird]

ok, and what filesystem are you using? and can you share a env|sort output? what OS is this? (i'm trying to gather some data, i have no obvious idea what the issue could be).
also, is it reproducable?

[jouvin]

@stdweird it seems to be my usual "mistake" of using mvn without clean. Obviously, as the tests create files, depending on the situation at the beginning of the test, the result may be different... To fix this, we should may be use a temporary directory created by mktemp instead of target/test/check.

[stdweird]

or create an alias to run mvn clean test, eg quattor/quattor.github.com#146 (comment)

[jouvin]

I personnally think that running clean should not be a requirement...

[jrha]

agreed