Re: [Flightgear-devel] Release engineering (aka, continuous integration, aka, nightlies)
On 17 Apr 2010, at 04:20, Tom P wrote: > That's an awesome setup, very interesting. > > Would you have a tarball of this configuration and some details of how you > set up the system? Quick answer is no, not yet, but I will. The configuration is exportable as XML files, and I'm using the official Hudson apt-get package for Ubuntu, so it's a fairly repeatable setup. Configuring the Windows slave VM with mingw is proving the biggest hassle - I have OSG working, but am having the usual environment issues building SimGear (the Hudson user environment/shell are set in a different way to a cmd.exe shell, or so it always seems) The Mac build is pretty close to producing a nightly, though - there I need to fix a genuine (and long-standing) configuration issue on Mac. In general, I find such systems are good for capturing how repeatable a build process is - and my experience on each of the Linux/mac/Windows slaves seems to confirm this :) James -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release engineering (aka, continuous integration, aka, nightlies)
Hudson was a Sun sponsored java.net project, the license is described as; Most of the art work is derived from Tango Project, and thus this portion of Hudson is covered by their license (Creative Commons Attribution Share-Alike license). The rest (that is, all the code, documents, build scripts, etc.) is covered by the MIT license, unless otherwise stated in individual files. For JEE coders, there is integration into the NetBeans IDE and so it is often run within the Glassfish application server. The administration is quite easy compared to some other systems, you just deploy it and run... S. > On Sat, 2010-04-17 at 14:21 +1000, George Patterson wrote: > > > Hi James, > > That looks very nice. I appreciate the self explained interface. > > What's the license for Hudson? > > Regards > > > George > > On Sat, Apr 17, 2010 at 1:20 PM, Tom P wrote: > > Hi James, > > > > That's an awesome setup, very interesting. > > > > Would you have a tarball of this configuration and some details of how you > > set up the system? > > > > Tom > > > > On Mon, Apr 12, 2010 at 2:50 AM, James Turner wrote: > >> > >> http://zakalawe.ath.cx:8080/ > >> > >> is a *prototype* build server for FG (including OSG and SimGear), running > >> on my home box - it will need a proper home if it moves beyond the > >> prototype > >> stage. > >> > >> For people who don't know, a build server talks to some slaves, and > >> grabs/builds/tests/packages code. The current server is talking to one > >> slave, which is an Ubuntu VM which is building Tim's 'next' branch on > >> Gitorious. > >> > >> The objective of such systems is that there should be *zero* human steps > >> to create a release - not just out of laziness, but for repeatability. I.e > >> don't write a checklist or 'howto' of creating a release, write a shell > >> script that does the steps. (Or several). And check those scripts into a > >> source control system, too. > >> > >> 'Soon' I will be setting up a WinXP slave, with a MinGW build. Hopefully > >> this will even extend to a NSIS installer script, if Fred has one lying > >> around. At which point we should have nightly installers available for > >> Windows, and a happier Fred. (A VisualStudio build is also possible, but > >> requires more interaction with someone else, who has an > >> externally-addressable/tunnel-able box with VS installed). > >> > >> (any slave could be a VM, of course - they use CPU while building, but > >> unlike other projects, our commit rate isn't that high - the slaves will be > >> idle most of the time) > >> (A Mac slave is also possible, but requires some more work, I will worry > >> about it assuming people want to pursue this whole concept) > >> > >> Build jobs can run arbitrary shell scripts - they can tag things in CVS or > >> Git, they can create tarballs, upload files to SFTP/FTP servers, the works. > >> So, if Durk/Curt/Fred could codify, somewhere, the steps (in terms of > >> 'things doable in a shell/.bat script') to create an FG pre-release and > >> final-release, I am happy to do the work to get the process automated. > >> > >> At which point, doing a release means clicking a button on a webpage (on > >> Hudson), and letting the slaves grind away for an hour or so. Magic! > >> > >> (Another thing the server can do, is email/IRC people when the build > >> breaks on Linux / FreeBSD / Mac / Win due to a commit - obviously very > >> handy > >> for the devs. Yet another thing it can do is run test suites - > >> unfortunately > >> we don't have many such tests) > >> > >> (If anyone wants to get into providing nightly .debs or .rpms, that could > >> also be done, but requires people who know those systems, and again can > >> provide a suitable externally address slave to run the builds) > >> > >> James > >> > >> > >> > >> -- > >> Download Intel® Parallel Studio Eval > >> Try the new software tools for yourself. Speed compiling, find bugs > >> proactively, and fine-tune applications for parallel performance. > >> See why Intel Parallel Studio got high marks during beta. > >> http://p.sf.net/sfu/intel-sw-dev > >> ___ > >> Flightgear-devel mailing list > >> Flightgear-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > > -- > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > ___ > > Flightgear-devel mailing list > > Flightgear-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > >
Re: [Flightgear-devel] Release engineering (aka, continuous integration, aka, nightlies)
Hi James, That looks very nice. I appreciate the self explained interface. What's the license for Hudson? Regards George On Sat, Apr 17, 2010 at 1:20 PM, Tom P wrote: > Hi James, > > That's an awesome setup, very interesting. > > Would you have a tarball of this configuration and some details of how you > set up the system? > > Tom > > On Mon, Apr 12, 2010 at 2:50 AM, James Turner wrote: >> >> http://zakalawe.ath.cx:8080/ >> >> is a *prototype* build server for FG (including OSG and SimGear), running >> on my home box - it will need a proper home if it moves beyond the prototype >> stage. >> >> For people who don't know, a build server talks to some slaves, and >> grabs/builds/tests/packages code. The current server is talking to one >> slave, which is an Ubuntu VM which is building Tim's 'next' branch on >> Gitorious. >> >> The objective of such systems is that there should be *zero* human steps >> to create a release - not just out of laziness, but for repeatability. I.e >> don't write a checklist or 'howto' of creating a release, write a shell >> script that does the steps. (Or several). And check those scripts into a >> source control system, too. >> >> 'Soon' I will be setting up a WinXP slave, with a MinGW build. Hopefully >> this will even extend to a NSIS installer script, if Fred has one lying >> around. At which point we should have nightly installers available for >> Windows, and a happier Fred. (A VisualStudio build is also possible, but >> requires more interaction with someone else, who has an >> externally-addressable/tunnel-able box with VS installed). >> >> (any slave could be a VM, of course - they use CPU while building, but >> unlike other projects, our commit rate isn't that high - the slaves will be >> idle most of the time) >> (A Mac slave is also possible, but requires some more work, I will worry >> about it assuming people want to pursue this whole concept) >> >> Build jobs can run arbitrary shell scripts - they can tag things in CVS or >> Git, they can create tarballs, upload files to SFTP/FTP servers, the works. >> So, if Durk/Curt/Fred could codify, somewhere, the steps (in terms of >> 'things doable in a shell/.bat script') to create an FG pre-release and >> final-release, I am happy to do the work to get the process automated. >> >> At which point, doing a release means clicking a button on a webpage (on >> Hudson), and letting the slaves grind away for an hour or so. Magic! >> >> (Another thing the server can do, is email/IRC people when the build >> breaks on Linux / FreeBSD / Mac / Win due to a commit - obviously very handy >> for the devs. Yet another thing it can do is run test suites - unfortunately >> we don't have many such tests) >> >> (If anyone wants to get into providing nightly .debs or .rpms, that could >> also be done, but requires people who know those systems, and again can >> provide a suitable externally address slave to run the builds) >> >> James >> >> >> >> -- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> ___ >> Flightgear-devel mailing list >> Flightgear-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release engineering (aka, continuous integration, aka, nightlies)
Hi James, That's an awesome setup, very interesting. Would you have a tarball of this configuration and some details of how you set up the system? Tom On Mon, Apr 12, 2010 at 2:50 AM, James Turner wrote: > http://zakalawe.ath.cx:8080/ > > is a *prototype* build server for FG (including OSG and SimGear), running > on my home box - it will need a proper home if it moves beyond the prototype > stage. > > For people who don't know, a build server talks to some slaves, and > grabs/builds/tests/packages code. The current server is talking to one > slave, which is an Ubuntu VM which is building Tim's 'next' branch on > Gitorious. > > The objective of such systems is that there should be *zero* human steps to > create a release - not just out of laziness, but for repeatability. I.e > don't write a checklist or 'howto' of creating a release, write a shell > script that does the steps. (Or several). And check those scripts into a > source control system, too. > > 'Soon' I will be setting up a WinXP slave, with a MinGW build. Hopefully > this will even extend to a NSIS installer script, if Fred has one lying > around. At which point we should have nightly installers available for > Windows, and a happier Fred. (A VisualStudio build is also possible, but > requires more interaction with someone else, who has an > externally-addressable/tunnel-able box with VS installed). > > (any slave could be a VM, of course - they use CPU while building, but > unlike other projects, our commit rate isn't that high - the slaves will be > idle most of the time) > (A Mac slave is also possible, but requires some more work, I will worry > about it assuming people want to pursue this whole concept) > > Build jobs can run arbitrary shell scripts - they can tag things in CVS or > Git, they can create tarballs, upload files to SFTP/FTP servers, the works. > So, if Durk/Curt/Fred could codify, somewhere, the steps (in terms of > 'things doable in a shell/.bat script') to create an FG pre-release and > final-release, I am happy to do the work to get the process automated. > > At which point, doing a release means clicking a button on a webpage (on > Hudson), and letting the slaves grind away for an hour or so. Magic! > > (Another thing the server can do, is email/IRC people when the build breaks > on Linux / FreeBSD / Mac / Win due to a commit - obviously very handy for > the devs. Yet another thing it can do is run test suites - unfortunately we > don't have many such tests) > > (If anyone wants to get into providing nightly .debs or .rpms, that could > also be done, but requires people who know those systems, and again can > provide a suitable externally address slave to run the builds) > > James > > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Release engineering (aka, continuous integration, aka, nightlies)
http://zakalawe.ath.cx:8080/ is a *prototype* build server for FG (including OSG and SimGear), running on my home box - it will need a proper home if it moves beyond the prototype stage. For people who don't know, a build server talks to some slaves, and grabs/builds/tests/packages code. The current server is talking to one slave, which is an Ubuntu VM which is building Tim's 'next' branch on Gitorious. The objective of such systems is that there should be *zero* human steps to create a release - not just out of laziness, but for repeatability. I.e don't write a checklist or 'howto' of creating a release, write a shell script that does the steps. (Or several). And check those scripts into a source control system, too. 'Soon' I will be setting up a WinXP slave, with a MinGW build. Hopefully this will even extend to a NSIS installer script, if Fred has one lying around. At which point we should have nightly installers available for Windows, and a happier Fred. (A VisualStudio build is also possible, but requires more interaction with someone else, who has an externally-addressable/tunnel-able box with VS installed). (any slave could be a VM, of course - they use CPU while building, but unlike other projects, our commit rate isn't that high - the slaves will be idle most of the time) (A Mac slave is also possible, but requires some more work, I will worry about it assuming people want to pursue this whole concept) Build jobs can run arbitrary shell scripts - they can tag things in CVS or Git, they can create tarballs, upload files to SFTP/FTP servers, the works. So, if Durk/Curt/Fred could codify, somewhere, the steps (in terms of 'things doable in a shell/.bat script') to create an FG pre-release and final-release, I am happy to do the work to get the process automated. At which point, doing a release means clicking a button on a webpage (on Hudson), and letting the slaves grind away for an hour or so. Magic! (Another thing the server can do, is email/IRC people when the build breaks on Linux / FreeBSD / Mac / Win due to a commit - obviously very handy for the devs. Yet another thing it can do is run test suites - unfortunately we don't have many such tests) (If anyone wants to get into providing nightly .debs or .rpms, that could also be done, but requires people who know those systems, and again can provide a suitable externally address slave to run the builds) James -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
