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

Jakub Hrozek jhrozek at redhat.com
Tue Jun 24 09:46:35 UTC 2014


On Tue, Jun 24, 2014 at 12:29:23PM +0300, Nikolai Kondrashov wrote:
> 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.

I will ask Kamil, but it indeed looks like nothing was implemented.
(which is in line with what he'd told me earlier - patches welcome)

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

Yes, we can try this way. I wonder how much effort will it be to manage
the suppresion files, though, NSS is not the most stable software out
there.

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

OK, I added "SSSD Continuous integration" milestone.



More information about the sssd-devel mailing list