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