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

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Tue Jun 24 09:29:23 UTC 2014


On 06/24/2014 09:55 AM, Jakub Hrozek wrote:
> On Wed, Jun 11, 2014 at 07:34:31PM +0300, Nikolai Kondrashov wrote:
>> On 06/11/2014 05:54 PM, Pavel Reichl wrote:
>> We can use Valgrind suppressions to achieve something close to this. Clang
>> doesn't seem to have such facility, but it is probably possible to implement
>> one which would process resulting XML files.
>
> Kamil Dudka of Red Hat (kdudka at r.c) has developed a tool that does exactly this
> diffing for Coverity results. When we talked about this tool about a
> year ago maybe, the didn't have the same functionality for Clang
> diffing, but maybe times have changed :-)
>
> Would you like to ping him or should I ?

I see minor references to Clang in the source code, but none in the
documentation, so it's not clear. I would be grateful, if you'd ping him.

However, I should note that there are no csdiff packages in Debian repos,
which means Debian users will be out in the cold either skipping this test, or
perhaps using "alien" to install csdiff.

>> However, I think that effort to do this is much greater than the effort
>> required to bring errors/warnings to zero, using various exception mechanisms
>> where necessary, and then simply keeping it there.
>
> When you're talking about warnings and errors, what valgrind mode do you
> have in mind? Also leaks or "just" bad memory access? If the former,
> then I think that's a large goal (NSS the crypto library would need an
> elaborate suppression file..), but the latter I think we should
> achieve. Did you see anything like undefined memory access during your
> CI patch testing? I would consider those an SSSD bug.

I was talking about the default tool, memcheck. Currently CI checks for error
counts, which include lost memory blocks and there are a lot of them. Pity
about the NSS, I see that crypto-tests shows many leaks from it, although
these are still not the majority.

I would say we can manage the suppressions for those leaks that we can't/won't
fix at the moment (wildcard them, if necessary) and fix the rest.

An in-tree suppressions file, which can be modified in a single commit with a
code change and then verified by the CI, seems to me almost as good as a
report difference tracking tool and much easier to implement.

Valgrind also supports outputting information on which suppressions were
actually used, so in time we will be able to use that to remove unused
suppressions, not only to add new ones.

>> One thing that would probably need this is code coverage tracking. I'm
>> considering storing at least the overall score somewhere and comparing each
>> run to the previous commit, alerting on reduction. However, I wouldn't attempt
>> to implement this right now, as it is mostly a convenience. Perhaps a few
>> months later.
>
> yep. btw what about a Trac Milestone that would list all these CI
> enhancements, maybe also tests we want to implement?

This sounds good. I haven't found a way to create a milestone myself, so I
assume I'm not permitted to. Could you please do it?

Thank you.

Sincerely,
Nick



More information about the sssd-devel mailing list