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

Jakub Hrozek jhrozek at redhat.com
Tue Jun 24 06:55:06 UTC 2014


On Wed, Jun 11, 2014 at 07:34:31PM +0300, Nikolai Kondrashov wrote:
> On 06/11/2014 05:54 PM, Pavel Reichl wrote:
> >On Wed, 2014-06-11 at 17:28 +0300, Nikolai Kondrashov wrote:
> >>
> >>>>Sure, there are various ways to make Valgrind happy, although none of them are
> >>>>very easy. The important thing is that we would have a way to track it now.
> >>>>This way, or another we should arrive to zero Valgrind errors.
> >>>>
> >>>Ignoring is not a good way for CI. We need to find a viable solution.
> >>
> >>I agree and I'm not saying we should ignore it always. This ignoring is to
> >>enable CI earlier, so we can get at least *some* tests to run. And having CI
> >>running these tests (even though they're ignored) will make fixing the
> >>failures easier, than without the CI. If only for the ability to trigger
> >>background runs on various distros at once. Once we have the issues fixed we
> >>will enforce the check.
> >>
> >
> >Is it viable option to somehow "store" current problems found by
> >valgrind/clang/other tools and just report the new ones?
> >
> >Doing so would allow us to use all benefits of this tools without need
> >to promptly fix issues created over years and we could use this approach
> >to mask false positives.
> 
> 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 ?

> 
> 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.

> 
> 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?



More information about the sssd-devel mailing list