[SSSD] [RFC] Add basic support for CI test execution

Lukas Slebodnik lslebodn at redhat.com
Wed Jun 18 11:45:30 UTC 2014


On (18/06/14 14:33), Nikolai Kondrashov wrote:
>On 06/18/2014 10:58 AM, Lukas Slebodnik wrote:
>>On (17/06/14 20:24), Nikolai Kondrashov wrote:
>>>On 06/11/2014 02:52 PM, Nikolai Kondrashov wrote:
>>>>On 06/11/2014 10:52 AM, Lukas Slebodnik wrote:
>>>>>>+        if [ "`xqilla -i \"\$f\" /dev/stdin \
>>>>>             Could you use xmllint instead of xqilla.
>>>>>We need xmllint for building manual pages. I didn't try it, but here is the 2nd
>>>>>link from quick google search.
>>>>>http://stackoverflow.com/questions/15461737/how-to-execute-xpath-one-liners-from-shell
>>>>
>>>>Ah, I didn't know xmllint could that. Thank you.
>>>>I tested it and will change to xmllint in the next version.
>>>
>>>Unfortunately, xmllint version in RHEL6 doesn't support that. So, although I
>>>already implemented its use, I'll have to go back to xqilla, which luckily
>>>exists on RHEL6.
>>"XPath tool" is necessary for extraction count of warnings from scan-build.
>>scan-build is not available in rhel6 it is only in epel6 and there is the same
>>version as in fedora [1]
>
>Well, we can't avoid using EPEL anyway, or can we?
>We need it for lcov and mock as well.
It is not problem with epel itself.

>>Could you explain why we need to run static analysis with the same version of
>>clang/llvm twice?
>
>We don't and we discussed this before. I just don't want to complicate the
>first release of CI and further postpone its use. Let's start with this. I'll
>work on separating distro-independent parts (including mock) afterwards.
>
If you prefer to have distro specific parts in another version of CI script
then static analysis should be also in different part (maybe 3rd) as well
and 1st version of CI scipt will be much simpler.

>At least, as a minor positive side effect, this would allow executing most of
>the tests on RHEL6 too.
What kind of test do you mean? Is ther any problematic test on RHEL6?

LS



More information about the sssd-devel mailing list