Coverity reports for test suite

[Nikolay Sivov]

On 26.02.2017 21:32, Austin English wrote:
> On Sun, Feb 26, 2017 at 12:09 PM, Nikolay Sivov <bunglehead at gmail.com> wrote:
>> On 26.02.2017 20:53, Alex Henrie wrote:
>>> Hello,
>>>
>>> I recently noticed that we don't currently get Coverity reports for
>>> files in the test suite. I emailed Amine Khaldi, who does the Coverity
>>> reports, and asked if we could start getting reports on the tests.
>>> Amine made it sound like this had been discussed before and due to the
>>> large volume of reports, there was not interest in getting reports for
>>> anything other than the actual Wine code.
>>>
>>> Is there enough interest now to start looking at the test suite
>>> reports? Would it hurt anything to be able to see that information?
>>>
>>> -Alex
>>>
>>>
>>
>> Yes, we discussed this on irc at some point, by we I mean Amine and
>> myself, and that's probably what he meant. I don't think it makes sense
>> to scan tests yet, I'd expect noise rate to be overwhelming, resulting
>> in thousands on reports of little to no value, like missing return value
>> checks. We still have hundreds of potentially valuable ones for
>> implementation part, that not a lot of people are looking at.
>>
>> So for the last question, I'm worried that it would hurt in a way that
>> reports we potentially care about will get buried. Of course I could be
>> wrong, we could simply try once and see what happens. I'm not sure
>> actually what happens to reports when next scan does not include failed
>> files, you'll probably lose all comments, report status updates etc.
>>
>> If you have time to clean some of existing ones, that would be greatly
>> appreciated.
> 
> FWIW, coverity supports putting issues into different components based
> on filename. It would be trivial to set up two different components
> for wine, e.g., 'wine' and 'wine-tests', then have wine/*/*/tests/* go
> to wine-tests, and wine/* to wine.
> 
> For those not familiar with coverity administration, this would not
> require two separate builds, the results are separated when results
> are displayed on the server.
> 

If it's possible to make them appear separately, so tests don't affect
our main reports, I see no harm in scanning tests too.