Build and Unit Tests - Hardware Sponsor?

[Milian Wolff]

Andreas Pakulat, 02.06.2011:
> On 02.06.11 12:55:52, Milian Wolff wrote:
> > Hey all, greetings from the KDevelop sprint at Randa!
> > 
> > If you are interested in what we are up to, see:
> > 
> > http://techbase.kde.org/Projects/KDevelop4/Meeting2011
> > 
> > Anyhow, back to the actual reason for this email. We want to improve the
> > quality of our codebase by doing automated build- and unit tests. For
> > simplicity running it all once per day would suffice already. Required
> > for that would be hardware, some kind of server. Hence this request:
> > Anyone has hardware to sponsor to us?
> > 
> > Personally I only see these requirements:
> > * shell access without root rights should suffice
> > * admin available to install dependencies if required
> > * ~1GB of memory for us to burn, and some common cpu
> > note: I want to enforce a ulimit and time limit for unit tests
> > 
> > If you want to help KDevelop and have something like this available,
> > please get in touch with us.
> > 
> > Furthermore if someone has any knowledge on setting up a consecutive
> > build and test runner, share your knowledge (PovAddict?).
> 
> Since most devs build KDevelop anyway (and should also run unit-test)
> you could also check with Alex Neuendorf about the cdash/ctest scripts
> he has which submits build and test info from a users machine to the
> public cdash dashboard.

The issue we/I want to solve is also to make people aware of induced API 
breakages. We want to reinforce people taking a look after "stable"¹ code, 
i.e. whenever changing something in kdevplatform make sure kdevelop builds 
(everyone does that) but people seldomly (if ever?) build php, php-docs, 
custom-buildsystem, and all those which are about to come.

So here cdash/ctest is not an option. If at all it could be used together with 
a cronjob.

¹: everything in 
https://projects.kde.org/projects/extragear/kdevelop/{kdevelop,kdevplatform,plugins}

> As a CI-tools I can recommend hudson, that eliminates the need to write
> git-monitoring and other stuff oneself. Only downside might be that it
> may not have the necessary plugin to properly understand the unit-test
> result files and hence won't be able to provide tha nice over-time
> report for test failures/success.

thanks, I'll take a look at that.

bye

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- 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/kdevelop-devel/attachments/20110602/1e7e5760/attachment.sig>