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

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Thu Jun 12 19:53:35 UTC 2014


On 06/11/2014 05:28 PM, Nikolai Kondrashov wrote:
> On 06/11/2014 03:46 PM, Lukas Slebodnik wrote:
>> On (11/06/14 14:52), Nikolai Kondrashov wrote:
>>> On 06/11/2014 10:52 AM, Lukas Slebodnik wrote:
>>>> I would prefer to split this function into two parts.
>>>>      * running static analyser
>>>>      * code coverage.
>>>> The compilation with scan-build is slow and it is not necessary for code
>>>> coverage.
>>>
>>> Do you mean that someone would prefer running one without the other? Which one
>>> is more important in your opinion? Would you run one of them locally?
>>>
>> yes, they are two different things.
>
>>> I'd personally run Clang more often than the code coverage collection just to
>>> catch coding mistakes.
>>>
>> me too.
>
> So, when would you like to run each of them, what would be your usage pattern?

Lukas, could you please answer the above?

I don't want to implement the ability to run arbitrary builds and tests with
bare Bash as it would seriously complicate the code. Epoxy will help here,
but I'd like to postpone work on its adoption until we've proven the
usefullness of CI tests.

So, I'll have to provide only two or at most three sets of tests to choose
from. Where would you rather see the Clang and Lcov execution? In the
short/(medium/)long set?

Currently they're both in the long (full) set, which executes in about 15
minutes. The short (essential) set is just above 2 minutes.

The Clang execution overhead is about 5 minutes. We can combine it with either
of the builds, having a dedicated build for it seems a waste.

There doesn't seem to be more than a minute of overhead for collecting
coverage data, but we need a dedicated build for it.

So, Lukas, do you have any ideas/preferences? Anyone else?

>>>>> +    stage lcov-merge        lcov --add-tracefile lcov_base.info \
>>>>> +                                 --add-tracefile lcov_check.info \
>>>>> +                                 --output-file lcov.info
>>>> Could you also remove output for external libraries and tests.
>>>>      lcov --remove libbash_test.info "/usr*" ...
>>>
>>> I can use "--no-external". What is "libbash_test.info"? What does passing
>>> "/usr*" to lcov do?
>> "libbash_test.info" is a copy&paste error from another script.
>> it is not problem with external. lcov will generate code coverage
>> for tests: "src/tests". It will slightly increase percentage of code coverage.
>
> My idea for including these was to allow seeing which test code actually
> executes. If having this is less usefull than not having, then I can exclude
> them.

After thinking a little, it seems including tests in the main coverage report
and score would be wrong. I'll remove them from there and will consider making
a separate report just for them.

Nick



More information about the sssd-devel mailing list