cppcheck on build.kde.org

[Ben Cooksley]

On Thu, Dec 18, 2014 at 6:30 AM, Jan Kundrát <jkt at kde.org> wrote:
> On Tuesday, 16 December 2014 23:58:02 CEST, Ben Cooksley wrote:
>>
>> If we were to replace Jenkins, you have indicated that custom work
>> would be required to get reports for tests and tools like cppcheck
>> generated and published.
>
>
> Hi Ben, what I said is that generating pretty plots about historical trends
> of the number of build warnings and the number of cppcheck issues is
> something which Jenkins excells at, that I do not see any value in having
> these graphs, and that they do not make sense in case of pre-merge CI. With
> a pre-merge CI, there's no linear history anymore, so having Jenkins-style
> graph showing how many warnings were produced over the course of last week
> is a metric which, IMHO, doesn't make sense. How should such a graph look
> like, considering that the history might have many dead-ends?

The graph is more useful for the post-merge phase I will admit. It is
used by developers to track their progress and to watch for
deviations, so I know it is useful.
Please remember to see both sides of the coin here. Pre-merge CI is
not the only type of CI.

Regardless - we should only have *one* system for doing CI runs,
regardless of whether they are post or pre merge.
Two systems would mean twice the maintenance effort (projects have to
be registered with it, etc) - and need twice the infrastructure unless
they can somehow collaborate on who is using which resources. That is
simply wasteful.

>
> I made a quick look into getting the cppcheck data published into Gerrit,
> but when testing this, I got back data which I cannot interpret properly.
>
> 1) For KIO's master branch with Qt5 (this is KF5, right?), the website [1]
> says that there are no errors, no warnings. However, if I run the tool
> locally on my laptop with no arguments, I get:
>
> [src/widgets/jobuidelegate.cpp:78] -> [src/widgets/jobuidelegate.cpp:75]:
> (error, inconclusive) Possible null pointer dereference: w - otherwise it is
> redundant to check it against null.
>
> If I use the same arguments as specified in websites/build.kde.org's
> config/build/global.cfg, I get a *ton* of warnings. Even after filtering out
> missing include files, I still get quite a few warnings, such as:
>
>  <error id="uninitMemberVar" severity="warning" msg="Member variable
> 'KUrlCompletionPrivate::list_urls_no_hidden' is not initialized in the
> constructor." verbose="Member variable
> 'KUrlCompletionPrivate::list_urls_no_hidden' is not initialized in the
> constructor.">
>
> 2) I don't see any cppcheck results for Trojita. The web page at [2] says
> "This plugin will not report Cppcheck result until there is at least one
> success or unstable build.", but there have been 278 such builds so far. I
> got similar results for the other build variations.
>
> Now, I might be doing something terribly wrong. Could you please point me in
> a right direction?
>
> -> Are you sure that the version of cppcheck on build.k.o works properly
> right now? All projects which I ranodmly picked report 0 warnings; that's
> surprising given that there are some compiler warnings and I've always got
> more invalid warnings from cppcheck than from my compiler(s).

The version works perfectly fine. cppcheck simply is not run for the
majority of projects as it is not enabled to conserve resources.
cppcheck, much like gcovr (Cobertura in Jenkins) are only enabled on
request for a project.

See various files in config/build/ for an example of how this is done.
Zanshin and Skrooge use this.

It is also disabled by default as for some projects it can make builds
take an extremely long time to finish - due to the copying over to the
Jenkins master of materials needed to produce the reports. This
affects kdelibs in particular.

>
> -> How are the custom include directories passed to cppcheck? Can it find
> the headers of the dependencies?

Not sure if this is needed - previously it has worked fine. This could
be due to our environment variables though.

>
> Cheers,
> Jan

Regards,
Ben

>
> [1] http://build.kde.org/job/kio_master_qt5/470/cppcheckResult/
> [2] http://build.kde.org/job/trojita_master_qt5/cppcheckResult/nodata
>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/