Nightly test runs from 2008-10-02_01:15:02

M Breugelmans mbr.nxi at gmail.com
Fri Oct 3 15:19:57 UTC 2008


On Fri, Oct 3, 2008 at 12:25 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> On 03.10.08 01:11:03, M Breugelmans wrote:
>> On Fri, Oct 3, 2008 at 12:54 AM, Andreas Pakulat <apaku at gmx.de> wrote:
>> >
>> > Right, a lot more we simply don't need. Also it puts up quite some
>> > requirements, basically a full blown php+mysql server. My little script
>> > doesn't need any of that and still works just fine as far as I can see.
>>
>> I'm going to have to disagree with that. Which of it's features is
>> bloated in your opinion? None that I can think of ;)
>
> You're not understanding what I'm saying. To run KDevelops and
> KDevPlatforms tests its currently totally sufficient to simply build them
> and then run ctest. We currently don't need anything but that and CDash has
> a lot more to offer, which we just don't need right now. Hence its
> "useless" features for us right now.
>
>> Php and mysql are pretty standard gear for a server anyway.
>
> That depends on what the server does, and the machine I'm sparing here to
> do the build+test is my desktop workmachine which has neither of the two
> installed.
>
> If you want to find a server to setup CDash on, thats fine with me, I'll
> make sure I send my builds over. But setting up CDash on my workmachine,
> just to run the tests for our two modules is simply wasted time IMHO.
>
>> CDash shines especially with multiple build configurations, eg when we
>> got a windows build bot up as well.
>
> And who will fix the errors if there are any? Most of the time its nothing
> simple, so you need someone with a windows system that can build kdevelop
> and a good bunch of MSVC knowledge to find and fix the error.

Depends on the frequency. Ideally you've got continuous feedback which
narrows it down to just one change. If this is the case it's much
much, much easier to fix problems [or revert]. But that requires a
significant amount of resources, probably unrealistic for any project
without sponsoring.

> If nobody fixes the found problems its pretty much wasted time/energy to do
> automated builds/tests. Thats why koffice has no test-runs anymore - nobody
> cared.
>

No, stronger. It's downright dumb to _write_ automated tests if you'r
not going to keep them running. For the same reason that it's dumb to
use a high level language if you'r not going to keep the code
compiling. Continuous failure reports are just a way to get more
feedback but totally pointless for a rotten suite.


Manuel




More information about the KDevelop-devel mailing list