Re: [Tsp-devel] Continuous integration ?

[Stephane GALLES]

Eric Noulard wrote:
> 2007/2/21, Stephane GALLES <address@hidden>:
>> > I really don't know if cruisecontrol is supposed to support this
>> > but seems to me more easy to obtain than a networked
>> > build server.
>> No, quite the contrary. It would be easier to obtain one single
>> continuous integration server, because one single server in enough
>> for all developpers.
>> More than one integration server is kind of meaningless.
> 
> For a Java code it may be true.
> This is not quite true for TSP in C , since it should be able
> to build:
> - on Linux i386
> - on Linux x86_64
> - on Linux PPC (coming soon)
> - on  VxWorks (some flavor)
> - on Solaris at least Sparc version
> - on Win32
> 
> You cannot (easily) achieve this with one box.

You're right, I've completly underestimated the importance of this major
point for TSP.

I implicitly thought that maybe it could be achieved with
cross-compilation in some cases, but it would be almost useless most of
the time as we really need to test the build with the native tools of
the plateform.

Hum...Too much time in Java and Ruby world, I thinks I'm totally biased,
coz of the "written somewhere, work anywhere" effect :)  (and, no,  no,
do not see in this sentence a way to start a troll  ;) )

> 
>> And, this server does not need to be remotely accessible.
> 
> I understand that, when I said "networked machine" I was thinking about:
> "
> the ci server should be able to:
>  - access the source control machine (CVS on Savannah)
>  - send mail or another network protocol for reporting

OK, we really were talking about the same thing.

[...]

> 
> A single reference build server won't give you enough to ensure
> the different build cases we aim at providing.
> 
> Nevertheless I get your point, if we want to ensure the TSP build smooth
> on Linux i386 with no GTK installed we should set up such a ci server.
> 
[...]
> 
> I was thinking about something like low-priority cron jobs
> which seems really like a sustainable activity. This is OK for build test
> but not really for running 'functional' test.
> 
>> And you REALLY, REALLY, REALLY don't want to test the build on the
>> developper's check out directory.
> 
> Of course and you are right.
> I was really thinking about a cron-like jobs that runs on separate disk
> space
> (may even create special user tsp_build for this task).

I totally agree with the dedicated user idea, but I think you can't
easily simulate a ci software with a simple cronjob, unless you're going
to program a more sophisticated scheme.

Indeed, when the build is going to be broken, and not fixed for a while,
the developper is going to be spammed, as an email is going to be sent
for each broken build cronjob, and a "success" email is not going to be
sent, when the build be fixed. Or, you may find an other way to warn the
developper

That's why, if you want a ci process on all developpers PC, you may
setup a ci software on these machines, instead of a cronjbob, and
program the ci software to send an email only to the owner of the PC.
Having said that, I don't know if I'd like to have a Tomcat continuously
running on my desktop...

however, I understand that a ci softwares may not be available for all
the platforms, as maybe a recent JVM won't be available (see ? I'm
learning from my mistakes ! )


[...]
>>
>> 2 - you really need only one integration server, and only one.
>> I think it is self explanatory.
> 
> yes it is I agree, but not for multi-platform software as TSP.

Yes, and I really think that's your answer that's self explanatory now,
and mine is meaningless !

> 
>     Then you wait the next power cycle to get the next build test.
>     <troll>
>     Besides if every TSP developer has its box off
>     you should not be worried about commit that could break the build :))
>     </troll>
      <troll bad_faith="true">
        Unless the developper turns his PC off, or shut his laptop's lid
        before the next test build ;)
      </troll>
[...]

> 
> I really think that you MUST have AT LEAST one reference "ci box" but
> 
> I'm pretty sure it is not enough for ensuring a smooth
> download && cmake && make && install && run
> for many current and forthcoming TSP users.
> 
> look at some not already closed TSP bugs:
> bug #18681: Build fails if libxml2 is not present
> bug #17035: Core dump si fichier /etc/hosts incorrect
> bug #16956: XML2 : can not compile libtspcfg under Solaris
> bug #16752: Bug in compilation under RHEL 64bits
> 
> They are related precisely to specific box configuration issue.

Yes, in the case of TSP, the ci server configuration maybe a moving
target that necessitates more administration than for a Java project.

> [...]
>> - the build must be done in a clean directory, you do not want the
>> build to succeed because a file the developper has forgotten to check in
>> is in this directory.
> 
> I understand that and I totally agree,
>   - kind of cron job should automate the build activity
You'll have to solve the spam problem but it shouldn't be complicated
(now, to anwser one of your question : no, you can't use cruisecontrol
with a cronjob, cruisecontrol must be continuously running as a service)

>   - separate 'user' or chrooted sandbox or whatever to be kept
>     away from "main user" files and be able to delete everything
>     you want if you have to.
> 
> In order to summarize my point about this is:
> 
> 1) YES a usual TSP ci server as Stephane kindly explained
>    seems very interesting to
> 
> 2) NO it does not catch most of the build trouble we had and will have
>    since TSP toolkit may be compiled in very different ways
>    on different configuration WHICH is a GOAL TSP should achieve
>    (this is my personal opinion though).
> 
> 

Thanks for having clarified these use cases.

Stephane.