views:

1134

answers:

4

Right now we are building a number of C++ apps for Win32 platform. We will be soon porting to Linux and then maybe more (32 and 64 bits for both).

What is the standard practice , do you use multiple hudson servers each on their own platform to do a build, or does the hudson service create VMs and do builds?

It is not clear to me the best practical way to do this.

Ideally I just want one box with a bunch of VMs running hudson, and then it kicks off builds as needed.

Is there a resource someone can point me to for this?

+2  A: 

I've never used hudson for C++ but for what you are planning to do, it might make sense to look at the VMWare plugin and see if it will do what you want. I would recommend having only a single Hudson master if possible. What you most likely want to do is set up a VMWare machine image with a Hudson Slave process for each target environment then spawn a build in that Slave.

sal
That is the ideal goal, but I am not sure how practical that is. I just have to play around with it I guess.
Tim
+2  A: 

I have played with hudson in a multiple platform scenario a bit more than a year ago. I had one hudson server (which was ridiculously easy to setup) on some machine and separate build slaves for each of the platforms. I remember that for a while one of the build clients was in a VirtualBox on the machine that hosted the hudson server. (I think I had the server on a VM for a while, too.) I cannot remember there being any principle problem with this setup.

However, if you want to have several virtual build machines building on the same physical machine I think you'd need a very powerful machine for that. C++ compilation takes quite an amount of resources and, IIRC, when hudson starts a build, it starts it on all platforms at the same time.

sbi
Yep - I realize that we may have to have multiple machines and in that case it may or may not be simpler to just have hudson running on each platform, though that is silly. Ideally I want the one hudson server to trigger each slave. I guess I just have to bite the bullet and buy additional hardware.
Tim
Tim, you just need _one_ hudson server, not one for each platform. But you will need one build slave per platform. You can test this with virtual machines until you think it's working, but in the end you probably won't enjoy CI if you build three platforms in VMs on the same physical machine.
sbi
It's fairly important to understand that you only ever* need 1 hudson server. You can do everything else with slaves installed on appropriate architectures.(* for reasonable interpretations of ever)
Jim T
+3  A: 

We use Hudson to manage C/C++ (GNU C, GNU C++, Watcom C) builds for multiple OSs. For us, software is built for Linux, Linux x64, QNX 4, and QNX6. The way we have it set up is:

  • 1 x VM for the Hudson server, running Windows
  • 4 x VMs, one for each slave type, so I have 4 Hudson slaves - 1 each for QNX4, QNX6 and Linux 32 and Linux 64. All of them are running on the same server, just as different VMs, and we have faced no problems. We build about a 100 projects, divided almost equally between the 4 system types.

You should not require any additional hardware. There is a Hudson plugin that works with VMWare VMs, to start them up and shut them down as required.

I hope that helps.

Sagar
Thanks - it sounds like a good set up for us as well.
Tim
I set up our system from scratch, so I know it takes time, but it is not hard. I Just realised that your question was posted last year. Did you get anything running?
Sagar
you have any tips for setting up the reverse. current system is linux, and other builds need to be run under windows.
garbagecollector
It is just as easy. I just moved my Hudson server to linux and use it to manage all my build slaves.Hudson can control Windows slaves using Windows service. When you set it up to use new nodes (slaves), you have the option of choosing how to connect the slave. Just pick "Windows service". It is pretty straight forward.
Sagar
+1  A: 

Note that there need not be any relation between the server that's running Hudson and the slave machines that are building your software apps. Due to the magic of Java, you can connect the disparate slave machines to the master using JNLP. (one example) So, whether they are physical or virtual machines, you can have one running Windows, another Linux; one 32-bit, another 64-bit; etc -- whatever your apps require. As long as they all have the JRE installed they can connect to the Hudson master and report the status of the builds.

William Leara