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

Pavel Reichl preichl at redhat.com
Wed Jun 11 17:14:03 UTC 2014


On Wed, 2014-06-11 at 19:34 +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.
> 
> 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.

I haven't looked closely on this so I trust your opinion.

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

That sounds great. BTW I really like how convenient it's now to get
coverage results thanks to your script.
> 
> Nick
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel





More information about the sssd-devel mailing list