Setting up a Quality Team within KDE

Martin Gräßlin mgraesslin at kde.org
Wed Apr 11 10:39:11 BST 2012


On Tuesday 10 April 2012 06:45:17 Laszlo Papp wrote:
> > all I care about is that its easy to get a project set up to
> > be build continously (and the unit-tests executed) and wether it
> > provides more than just build errors/warnings and test-results. Since
> > some of these things are handy - especially when working on libraries.
> 
> Could you please precisely enumerate the technical pros and cons so
> that we can all understand ? Thank you in advance!
There is actually nothing to compare the technical pros and cons. Jenkins and 
CDash solve different problems. CDash relies on someone running a build and 
submitting the result. Jenkins can be used to run a build after a push to the 
repository.

What I use Jenkins for is just not possible with CDash. I have a private 
Jenkins installation in additon to build.kde.org to get more or less instant 
results whenever kde-workspace changes. KWin for example has multiple build 
flags to e.g. hide some parts for Plasma Active. Whenever there is a commit 
Jenkins nicely compiles it for me with default build flags and if successful 
with other build flags. If it fails I get a mail telling me in most cases 
exactly which commit broke the build.

Afterwards it runs cppcheck on the source code and has the change in a nice 
graph. That means I see exactly in which build and by that in which commit an 
issue had been introduced. I have at least the plan to write a plugin for 
Krazy2 to do the same so that I see exactly with which commit an issue was 
introduced. The whole process takes on my system about one hour, which means I 
have more or less instant replies about introduced issues.

Now that is just something which is not possible with CDash, but CDash seems 
to solve other problems which Jenkins cannot solve that is crowd sourcing the 
test running.

But overall these are two very useful solutions which do not compete with each 
other and we should make use of them in a useful combined way, e.g. by 
submitting build results from build.kde.org to CDash.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120411/89172c2a/attachment.sig>


More information about the kde-core-devel mailing list