Re: [Tsp-devel] Continuous integration ?

[Eric Noulard]

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.

> 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
"
> Let me summarize how a continuous integration server is supposed to
> work, in order to explain why... :
> 1 - it is very easy to setup, with almost no maintenance once set up.
> 2 - you really need only one integration server, and only one.

This is where I think this is not true for the TSP case.
TSP is meant to be modular and should be able to (auto)configure
itself where it is built, this is the essence of using autotools in the first
place and CMake today.

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.

> 4 - If the continuous integration server is on a desktop (bad idea at
> first), you really don't want the continuous integration to have
> something to do with any manual activity on the desktop (and especially
> NOT the developpement activity of the user).

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).

> Whatever the continuous integration software (ci software) you choose,
> the basic principle is  always :
> 1 - The ci software runs as a service on the ci server. Every x minutes
[...]

all the steps may work on a user machine
(except unit test since it may interfere with the user/developper activity)
with slow update period
(every 2 hours for example)
> - go to step 1
>
> So, with this scenario, why :
> 1 - it is very easy to setup, with almost no maintenance once set up.
> Because, it works almost alone, and can work behind a firewall as the
> ci server does not need to be seen from the internet. It only needs to
> be able to do check out from the source control server. No security
> problem at all, all the more so as the ci server never do any check in ;
> he can do its check out as an anonymous source control user.

This is precisely the properties you have on a TSP developper box.

> 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.

> 3 - preferably, you don't want this integration server to be one of the
> developpers desktop, but, at worst, it may be the case
> For several reasons :
> - whenever a build occurs, it may bother the user (CPU 100%)
    Yes we shoud be careful about that, but I think it is manageable.

> - the PC might not be up all the time

    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>

> - but mainly : you want a ci server to act as a neutral reference
> configuration. You do not want a continuous build to succeed because
> on this particular PC, the developper has installed a particular version
> of a library (maybe the same version that makes its code
> compile...hum...only on his own desktop...)

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.

> 4 - If the continuous integration server is on a desktop (bad idea at
> first), you really don't want the continuous integration to have
> something to do with any manual activity on the desktop (and especially
> NOT the developpement activity of the user). And
> you REALLY, REALLY, REALLY don't want to test the build on the
> developper's check out directory.

Sure, I agree on that, I just mis-explained my point in the first place.
As I said 'on the developer box' BUT
in akind of sandbox from developper activity (but CPU cycle :))

> - self explanatory, you do not want to rely on a user to trigger
> the build by hand.
[...]
> - 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
  - 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).


--
Erk