http://opensimulator.org/api.php?action=feedcontributions&feedformat=atom&user=Daedius 2026-04-06T11:53:47Z User contributions MediaWiki 1.19.9 http://opensimulator.org/wiki/Automated_Testing 2008-03-08T06:33:41Z

<p>Daedius: /* Technologies */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> * Communication<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> Use NUnit, NCover<br /> <br /> ==Code Performance==<br /> Need to ponder<br /> <br /> ==Runtime Performance==<br /> [[Statistics Server]]<br /> <br /> ==Code Introspection==<br /> Use [http://mono-project.com/Gendarme Gendarme]<br /> <br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> ==Communication==<br /> We should be able to notify the right people of various important changes (or not so important if they wish) via Email, IRC, etc.<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [http://code.google.com/p/nanobot/ NanoBot]<br /> [[Category:Development]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-11T23:00:56Z

<p>Daedius: /* Code Introspection */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> * Communication<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> Use NUnit, NCover<br /> <br /> ==Code Performance==<br /> Need to ponder<br /> <br /> ==Runtime Performance==<br /> [[Statistics Server]]<br /> <br /> ==Code Introspection==<br /> Use [http://mono-project.com/Gendarme Gendarme]<br /> <br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> ==Communication==<br /> We should be able to notify the right people of various important changes (or not so important if they wish) via Email, IRC, etc.<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-11T23:00:34Z

<p>Daedius: /* Code Introspection */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> * Communication<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> Use NUnit, NCover<br /> <br /> ==Code Performance==<br /> Need to ponder<br /> <br /> ==Runtime Performance==<br /> [[Statistics Server]]<br /> <br /> ==Code Introspection==<br /> Use [Genderme http://mono-project.com/Gendarme]<br /> <br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> ==Communication==<br /> We should be able to notify the right people of various important changes (or not so important if they wish) via Email, IRC, etc.<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-11T22:56:53Z

<p>Daedius: /* Code Style */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> * Communication<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> Use NUnit, NCover<br /> <br /> ==Code Performance==<br /> Need to ponder<br /> <br /> ==Runtime Performance==<br /> [[Statistics Server]]<br /> <br /> ==Code Introspection==<br /> Use Genderme<br /> <br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> ==Communication==<br /> We should be able to notify the right people of various important changes (or not so important if they wish) via Email, IRC, etc.<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:51:16Z

<p>Daedius: /* Testing Objectives */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> * Communication<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> Use NUnit, NCover<br /> <br /> ==Code Performance==<br /> Need to ponder<br /> <br /> ==Runtime Performance==<br /> [[Statistics Server]]<br /> <br /> ==Code Style==<br /> Use FxCop<br /> <br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> ==Communication==<br /> We should be able to notify the right people of various important changes (or not so important if they wish) via Email, IRC, etc.<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:49:31Z

<p>Daedius: /* Code Test */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> * Communication<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> Use NUnit<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> ==Communication==<br /> We should be able to notify the right people of various important changes (or not so important if they wish) via Email, IRC, etc.<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:48:45Z

<p>Daedius: /* Web site results */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> * Communication<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> ==Communication==<br /> We should be able to notify the right people of various important changes (or not so important if they wish) via Email, IRC, etc.<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:47:47Z

<p>Daedius: /* Summary */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> * Communication<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:47:11Z

<p>Daedius: /* Web site results */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run for some spiffy grids<br /> * Build results for showing us what happens when things break<br /> * Code test results for showing us what tasts ran<br /> * Code performance for showing us how all our profiled code worked<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results for showing which code structure names are non-standard<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:45:20Z

<p>Daedius: /* Summary */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing result information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run<br /> * Build results<br /> * Code test results<br /> * Code performance results<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:43:41Z

<p>Daedius: /* Goal */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation so we can have better awareness of our changes to OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run<br /> * Build results<br /> * Code test results<br /> * Code performance results<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:39:59Z

<p>Daedius: /* Build Stability */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> Ensure that the build is intact.<br /> <br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run<br /> * Build results<br /> * Code test results<br /> * Code performance results<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:38:55Z

<p>Daedius: /* Crossplatform Support */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> * Build Stability - Make sure all our builds compile on every operating system<br /> * Code Test - Make sure all our tests run on every operating system<br /> * Code Performance - See how our functions run on every operating system<br /> * Runtime Performance - See how operating systems actually run opensim<br /> <br /> ==Build Stability==<br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run<br /> * Build results<br /> * Code test results<br /> * Code performance results<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:37:20Z

<p>Daedius: /* Crossplatform Support */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> There are a number of objectives that should report on which operating system they ran<br /> <br /> ==Build Stability==<br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run<br /> * Build results<br /> * Code test results<br /> * Code performance results<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:36:41Z

<p>Daedius: /* Code Test */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> ==Build Stability==<br /> ==Code Test==<br /> <br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run<br /> * Build results<br /> * Code test results<br /> * Code performance results<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:36:21Z

<p>Daedius: /* Web site results */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> ==Build Stability==<br /> ==Code Test==<br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> * Crossplatform Support information on tests that have been run<br /> * Build results<br /> * Code test results<br /> * Code performance results<br /> * Runtime Performance statistics information for bar graphs and charts<br /> * Code Style results<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:34:35Z

<p>Daedius: /* Web site results */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> ==Build Stability==<br /> ==Code Test==<br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> Results of our testing should be accessible web service. This web service will be available via a maintained plugin for build bot so when running a build bot master, one only need a website that can access the web service and properly show it how they wish. Our web service needs to be able to hand off a variety of information:<br /> * Realtime status information of operations<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:27:24Z

<p>Daedius: /* Testing Objectives */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> ==Crossplatform Support==<br /> ==Build Stability==<br /> ==Code Test==<br /> ==Code Performance==<br /> ==Runtime Performance==<br /> ==Code Style==<br /> ==Web site results==<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:25:39Z

<p>Daedius: /* Summary */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> To properly test OpenSim, we will need to address a number of objectives:<br /> <br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> We will be using a number of in-house technologies as well as 3rd party (NUnit, Nant, etc.) to address our challenges. We will strive to maintain all our testing tools in a package that any one can use on any computers with any operating system. For convience, a centralized site for this testing information on opensim will be created on http://testing.ambientunion.com .<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:22:12Z

<p>Daedius: /* Testing Objectives */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:22:01Z

<p>Daedius: /* Goal */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = Summary =<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> A centralized site for this testing information will be created on http://testing.ambientunion.com<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:21:47Z

<p>Daedius: /* Testing Objectives */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> * Web site results<br /> <br /> A centralized site for this testing information will be created on http://testing.ambientunion.com<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:21:03Z

<p>Daedius: /* Testing Objectives */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> <br /> A centralized site for this testing information will be created on http://testing.ambientunion.com<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:18:21Z

<p>Daedius: /* Testing Objective */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objectives =<br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:17:04Z

<p>Daedius: /* Testing Objective */</p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objective =<br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Performance<br /> * Runtime Performance<br /> * Code Style<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:16:32Z

<p>Daedius: </p> <hr /> <div>= Goal =<br /> To create a system of automatic building, testing, and simulation for OpenSim.<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Objective =<br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Style<br /> * Code Performance<br /> * Runtime Performance<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:12:36Z

<p>Daedius: /* People */</p> <hr /> <div>= Goal =<br /> To create a system that allows us to automatically build, simulate and test OpenSim.<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Testing Criteria =<br /> * Crossplatform Support<br /> * Build Stability<br /> * Code Test <br /> * Code Style<br /> * Code Performance<br /> * Runtime Performance<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:08:57Z

<p>Daedius: </p> <hr /> <div>= Goal =<br /> To create a system that allows us to automatically build, simulate and test OpenSim.<br /> <br /> = People =<br /> * Daedius Moskvitch ( daedius @@@@ daedius.com)<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:07:33Z

<p>Daedius: </p> <hr /> <div>= Goal =<br /> To create a system that allows us to automatically build,simulate and test OpenSim.<br /> <br /> = Technologies =<br /> * [[Statistics Server]]<br /> * [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:07:21Z

<p>Daedius: Replacing page with '= Goal = To create a system that allows us to automatically build,simulate and test OpenSim. = Technologies = Statistics Server Build Bot'</p> <hr /> <div>= Goal =<br /> To create a system that allows us to automatically build,simulate and test OpenSim.<br /> <br /> = Technologies =<br /> [[Statistics Server]]<br /> [[Build Bot]]</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-09T18:05:36Z

<p>Daedius: </p> <hr /> <div>[[Build Bot]]<br /> <br /> = Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> = Sources =<br /> svn co http://ambientunion.com/svn/buildbot/trunk<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> == 0.2 ==<br /> Released: January 5th, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, multithread a build process (or multiple build processes), distribute nant files locally, attempt compile, and return status<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.2.zip Sources]<br /> ===Features===<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * Interfacing of master-slave architecture<br /> * Linux, Windows, and OSX support<br /> * Initial slave configuration in external xml<br /> * Working slave that can multi-thread builds from masters<br /> * Simple status and result chain in builds run on slaves<br /> * Nant-based builds<br /> * Custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> ===Other Notes===<br /> * Be sure to copy the write App.Config to BuildBot.Net.exe.config, and set the argument BuildContainer equal to the path of the directory &quot;BuildContainer&quot;<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> <br /> = Planned Versions =<br /> == 0.3 ==<br /> Create a real master slave architecture (albiet simple one) to distribute our nant builds and retrieve statuses in real time<br /> <br /> * Build master to distribute nant files to build slave<br /> * Simple status plugin<br /> * Working status chain<br /> <br /> == 0.4 ==<br /> Finally get some results that are viewable to the public!<br /> * Create a website that uses javascript to display build statuses in realtime<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Statistics_Server 2008-01-09T18:01:05Z

<p>Daedius: New page: = Goal = Create a server that can poll a grid or region for statistics and report them to various outputs. = Why is this needed? = * There are more stats than those provided by the SL cli...</p> <hr /> <div>= Goal =<br /> Create a server that can poll a grid or region for statistics and report them to various outputs.<br /> <br /> = Why is this needed? =<br /> * There are more stats than those provided by the SL client a person is interested in<br /> * Statistics should be viewable without a SL client<br /> * Testing should make good use of grid/region statistics so we can know that our changes not only just work, but work well.<br /> <br /> = Features =<br /> * Crossplatform<br /> * Statistics Output Plugin Architecture ( IM, log files, console output, web pages, etc.)<br /> * Statistic Plugin Architecture (&quot;I want to know how many people are on a grid&quot;, &quot;I want to know what my system CPU is&quot; )</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-08T07:09:24Z

<p>Daedius: /* People */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> = Sources =<br /> svn co http://ambientunion.com/svn/buildbot/trunk<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> == 0.2 ==<br /> Released: January 5th, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, multithread a build process (or multiple build processes), distribute nant files locally, attempt compile, and return status<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.2.zip Sources]<br /> ===Features===<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * Interfacing of master-slave architecture<br /> * Linux, Windows, and OSX support<br /> * Initial slave configuration in external xml<br /> * Working slave that can multi-thread builds from masters<br /> * Simple status and result chain in builds run on slaves<br /> * Nant-based builds<br /> * Custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> ===Other Notes===<br /> * Be sure to copy the write App.Config to BuildBot.Net.exe.config, and set the argument BuildContainer equal to the path of the directory &quot;BuildContainer&quot;<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> <br /> = Planned Versions =<br /> == 0.3 ==<br /> Create a real master slave architecture (albiet simple one) to distribute our nant builds and retrieve statuses in real time<br /> <br /> * Build master to distribute nant files to build slave<br /> * Simple status plugin<br /> * Working status chain<br /> <br /> == 0.4 ==<br /> Finally get some results that are viewable to the public!<br /> * Create a website that uses javascript to display build statuses in realtime<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-05T08:07:36Z

<p>Daedius: /* 0.3 */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> == 0.2 ==<br /> Released: January 5th, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, multithread a build process (or multiple build processes), distribute nant files locally, attempt compile, and return status<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.2.zip Sources]<br /> ===Features===<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * Interfacing of master-slave architecture<br /> * Linux, Windows, and OSX support<br /> * Initial slave configuration in external xml<br /> * Working slave that can multi-thread builds from masters<br /> * Simple status and result chain in builds run on slaves<br /> * Nant-based builds<br /> * Custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> ===Other Notes===<br /> * Be sure to copy the write App.Config to BuildBot.Net.exe.config, and set the argument BuildContainer equal to the path of the directory &quot;BuildContainer&quot;<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> <br /> = Planned Versions =<br /> == 0.3 ==<br /> Create a real master slave architecture (albiet simple one) to distribute our nant builds and retrieve statuses in real time<br /> <br /> * Build master to distribute nant files to build slave<br /> * Simple status plugin<br /> * Working status chain<br /> <br /> == 0.4 ==<br /> Finally get some results that are viewable to the public!<br /> * Create a website that uses javascript to display build statuses in realtime<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-05T08:06:34Z

<p>Daedius: /* 0.4 */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> == 0.2 ==<br /> Released: January 5th, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, multithread a build process (or multiple build processes), distribute nant files locally, attempt compile, and return status<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.2.zip Sources]<br /> ===Features===<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * Interfacing of master-slave architecture<br /> * Linux, Windows, and OSX support<br /> * Initial slave configuration in external xml<br /> * Working slave that can multi-thread builds from masters<br /> * Simple status and result chain in builds run on slaves<br /> * Nant-based builds<br /> * Custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> ===Other Notes===<br /> * Be sure to copy the write App.Config to BuildBot.Net.exe.config, and set the argument BuildContainer equal to the path of the directory &quot;BuildContainer&quot;<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> <br /> = Planned Versions =<br /> == 0.3 ==<br /> Create a real master slave architecture to distribute our nant builds and retrieve statuses in realtime<br /> <br /> * Build master to distribute nant files to build slave<br /> * Simple status plugin<br /> * Working status chain<br /> <br /> == 0.4 ==<br /> Finally get some results that are viewable to the public!<br /> * Create a website that uses javascript to display build statuses in realtime<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-05T08:06:03Z

<p>Daedius: </p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> == 0.2 ==<br /> Released: January 5th, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, multithread a build process (or multiple build processes), distribute nant files locally, attempt compile, and return status<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.2.zip Sources]<br /> ===Features===<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * Interfacing of master-slave architecture<br /> * Linux, Windows, and OSX support<br /> * Initial slave configuration in external xml<br /> * Working slave that can multi-thread builds from masters<br /> * Simple status and result chain in builds run on slaves<br /> * Nant-based builds<br /> * Custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> ===Other Notes===<br /> * Be sure to copy the write App.Config to BuildBot.Net.exe.config, and set the argument BuildContainer equal to the path of the directory &quot;BuildContainer&quot;<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> <br /> = Planned Versions =<br /> == 0.3 ==<br /> Create a real master slave architecture to distribute our nant builds and retrieve statuses in realtime<br /> <br /> * Build master to distribute nant files to build slave<br /> * Simple status plugin<br /> * Working status chain<br /> <br /> == 0.4 ==<br /> * Create a website that uses javascript to display build statuses in realtime<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-04T16:35:56Z

<p>Daedius: /* 0.2 */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * Interfacing of master-slave architecture<br /> * Linux, Windows, and OSX support<br /> * Initial slave configuration in external xml<br /> * Working slave that can multi-thread builds from masters<br /> * Simple status and result chain in builds run on slaves<br /> * Nant-based builds<br /> * Custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-04T16:34:49Z

<p>Daedius: /* 0.2 */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * Interfacing of master-slave architecture<br /> * Linux, Windows, and OSX support<br /> * Initial buildbot.net slave configuration via xml<br /> * Eorking slave that can multi-thread builds from masters<br /> * Simple status and result chain in builds run on slaves<br /> * Nant-based builds<br /> * Custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-04T16:32:15Z

<p>Daedius: /* 0.2 */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * interfacing of master-slave architecture<br /> * linux, windows, and osx support<br /> * initial buildbot.net slave configuration via xml<br /> * working slave that can multi-thread builds from masters<br /> * status and result passing chain in slave<br /> * nant-based builds<br /> * custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-04T16:31:41Z

<p>Daedius: /* 0.2 */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * interfacing of master-slave architecture<br /> * linux, windows, and osx support<br /> * initial buildbot.net slave configuration via xml<br /> * working slave that can multi-thread builds from masters<br /> * nant-based builds<br /> * status and result passing chain in slave<br /> * custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-04T16:31:08Z

<p>Daedius: /* 0.2 */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * interfacing of master-slave architecture<br /> * linux, windows, and osx support<br /> * initial buildbot.net slave configuration<br /> * working slave that can multi-thread builds from masters<br /> * nant-based builds<br /> * status and result passing chain in slave<br /> * custom nant tags for notification of status within a nant process (i.e. &lt;status value=&quot;Running&quot; Description=&quot;Compiling OpenSim&quot; buildid=&quot;${build.id}&quot;/&gt; )<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-02T04:54:39Z

<p>Daedius: /* 0.2 */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build step support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python as a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:50:45Z

<p>Daedius: /* Status Delivery Architecture */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by web plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:47:55Z

<p>Daedius: /* BuildBot */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by the html.Waterfall plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing which we will be using extensively as a general direction<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:46:30Z

<p>Daedius: /* Comparison To Automated Build/Testing Methods */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by the html.Waterfall plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Other Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:46:15Z

<p>Daedius: /* Architecture Plans */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> The Buildbot consists of a single buildmaster and one or more buildslaves, connected in a star topology. The buildmaster makes all decisions about what, when, and how to build. It sends commands to be run on the build slaves, which simply execute the commands and return the results. (certain steps involve more local decision making, where the overhead of sending a lot of commands back and forth would be inappropriate, but in general the buildmaster is responsible for everything).<br /> <br /> The buildmaster is usually fed Changes by some sort of version control system (see Change Sources), which may cause builds to be run. As the builds are performed, various status messages are produced, which are then sent to any registered Status Targets (see Status Delivery).<br /> <br /> [[Image:BuildSystemHighLevel.png]]<br /> <br /> The buildmaster is configured and maintained by the “buildmaster admin”, who is generally the project team member responsible for build process issues. Each buildslave is maintained by a “buildslave admin”, who do not need to be quite as involved. Generally slaves are run by anyone who has an interest in seeing the project work well on their favorite platform. <br /> <br /> ==Build Slave Connections==<br /> <br /> The buildslaves are typically run on a variety of separate machines, at least one per platform of interest. These machines connect to the buildmaster over a TCP connection to a publically-visible port. As a result, the buildslaves can live behind a NAT box or similar firewalls, as long as they can get to buildmaster. The TCP connections are initiated by the buildslave and accepted by the buildmaster, but commands and results travel both ways within this connection. The buildmaster is always in charge, so all commands travel exclusively from the buildmaster to the buildslave.<br /> <br /> To perform builds, the buildslaves must typically obtain source code from a CVS/SVN/etc repository. Therefore they must also be able to reach the repository. The buildmaster provides instructions for performing builds, but does not provide the source code itself. <br /> <br /> [[Image:BuildSystemBuildSlaves.png]]<br /> <br /> ==Buildmaster Architecture==<br /> <br /> The Buildmaster consists of several pieces:<br /> <br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> <br /> * Change Sources, which create a Change object each time something is modified in the VC repository. Most ChangeSources listen for messages from a hook script of some sort. Some sources actively poll the repository on a regular basis. All Changes are fed to the Schedulers.<br /> * Schedulers, which decide when builds should be performed. They collect Changes into BuildRequests, which are then queued for delivery to Builders until a buildslave is available.<br /> * Builders, which control exactly how each build is performed (with a series of BuildSteps, configured in a BuildFactory). Each Build is run on a single buildslave.<br /> * Status plugins, which deliver information about the build results through protocols like HTTP, mail, and IRC. <br /> <br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> <br /> Each Builder is configured with a list of BuildSlaves that it will use for its builds. These buildslaves are expected to behave identically: the only reason to use multiple BuildSlaves for a single Builder is to provide a measure of load-balancing.<br /> <br /> Within a single BuildSlave, each Builder creates its own SlaveBuilder instance. These SlaveBuilders operate independently from each other. Each gets its own base directory to work in. It is quite common to have many Builders sharing the same buildslave. For example, there might be two buildslaves: one for i386, and a second for PowerPC. There may then be a pair of Builders that do a full compile/test run, one for each architecture, and a lone Builder that creates snapshot source tarballs if the full builders complete successfully. The full builders would each run on a single buildslave, whereas the tarball creation step might run on either buildslave (since the platform doesn't matter when creating source tarballs). In this case, the mapping would look like:<br /> <br /> Builder(full-i386) -&gt; BuildSlaves(slave-i386)<br /> Builder(full-ppc) -&gt; BuildSlaves(slave-ppc)<br /> Builder(source-tarball) -&gt; BuildSlaves(slave-i386, slave-ppc)<br /> <br /> and each BuildSlave would have two SlaveBuilders inside it, one for a full builder, and a second for the source-tarball builder.<br /> <br /> Once a SlaveBuilder is available, the Builder pulls one or more BuildRequests off its incoming queue. (It may pull more than one if it determines that it can merge the requests together; for example, there may be multiple requests to build the current HEAD revision). These requests are merged into a single Build instance, which includes the SourceStamp that describes what exact version of the source code should be used for the build. The Build is then randomly assigned to a free SlaveBuilder and the build begins. <br /> <br /> ==Status Delivery Architecture==<br /> <br /> The buildmaster maintains a central Status object, to which various status plugins are connected. Through this Status object, a full hierarchy of build status objects can be obtained.<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> The configuration file controls which status plugins are active. Each status plugin gets a reference to the top-level Status object. From there they can request information on each Builder, Build, Step, and LogFile. This query-on-demand interface is used by the html.Waterfall plugin to create the main status page each time a web browser hits the main URL.<br /> <br /> The status plugins can also subscribe to hear about new Builds as they occur: this is used by the MailNotifier to create new email messages for each recently-completed Build.<br /> <br /> The Status object records the status of old builds on disk in the buildmaster's base directory. This allows it to return information about historical builds.<br /> <br /> There are also status objects that correspond to Schedulers and BuildSlaves. These allow status plugins to report information about upcoming builds, and the online/offline status of each buildslave<br /> <br /> = Comparison To Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:40:03Z

<p>Daedius: /* Architecture Plans */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> [[Image:BuildSystemHighLevel.png]]<br /> [[Image:BuildSystemBuildSlaves.png]]<br /> [[Image:BuildSystemBuildMasterBuildSlaves.png]]<br /> [[Image:BuildSystemBuildDistrobution.png]]<br /> [[Image:BuildSystemStatusDelivery.png]]<br /> <br /> = Comparison To Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:38:31Z

<p>Daedius: /* Comparison To Automated Build/Testing Projects */</p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> <br /> = Comparison To Automated Build/Testing Methods=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:28:29Z

<p>Daedius: </p> <hr /> <div>= Goal =<br /> To create a crossplatform, distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> <br /> = Comparison To Automated Build/Testing Projects=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:28:03Z

<p>Daedius: </p> <hr /> <div>= Goal =<br /> To create a distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> <br /> = Comparison To Automated Build/Testing Projects=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius http://opensimulator.org/wiki/Automated_Testing 2008-01-01T21:27:14Z

<p>Daedius: /* Other Notes */</p> <hr /> <div>= Goal =<br /> To create a distributed continuous integration system for open simulator grids which can automate both builds and testing.<br /> <br /> <br /> = People = <br /> The list of people who are working to develop a solution:<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Features =<br /> * Crossplatform<br /> * Notification via email,irc,web<br /> * Master-Slave architecture<br /> * Nant support<br /> * NUnit support<br /> * Support for grid testing<br /> <br /> = Released Versions =<br /> == 0.1 ==<br /> Released: January 1st, 2008&lt;br&gt;<br /> A simple application that can detect changes on the opensim svn, attempt compile, and return whether it was successful or not<br /> * [http://buildbot.ambientunion.com/BuildBot.Net-0.1.zip Sources]<br /> <br /> ===Features===<br /> * svn source control support<br /> * svn change detection<br /> * linux and windows support<br /> <br /> ===Installation===<br /> Right now there is nant build files and visual studio 2005 solution. <br /> <br /> ===Special Notes For Running===<br /> After compiling the application, make sure you have the correct application configuration file for your operating system (the current default is Windows, it will fail on Linux if you do not change). Just rename the right App.config to &quot;BuildBot.exe.config&quot;.<br /> <br /> ===Other Notes===<br /> * Deletion can be problematic on windows<br /> * I think TortoiseSVN on win32 causes alot of trouble when deleting source control directories<br /> * Need more user friendly exceptions<br /> * A good way to force building, is to change the LatestTime.txt to a few days back ( to gaurantee that new changes are detected)<br /> * HAPPY NEW YEARS!<br /> <br /> ===Contributors===<br /> * Daedius Moskvitch (daedius @@@@@ daedius.com)<br /> <br /> = Planned Versions =<br /> == 0.2 ==<br /> Create a more configurable build runner via xml. This release will hopefully be a good precursor to having a real operational slave.<br /> <br /> * xml-defined build command support<br /> * osx support<br /> * initial buildbot.net configuration<br /> <br /> = Architecture Plans =<br /> <br /> = Comparison To Automated Build/Testing Projects=<br /> == CruiseControl.Net ==<br /> * Supporting the master slave architecture will be vastly different from CC's centralized approach, but it will allow us more flexability and decentralization of tests on many platforms. It will also enable us to run certain tests which require multiple computers for grid testing.<br /> * This project has a great system of xml specification for projects and support for Nant,Nunit,NCop, etc we could learn from thoug<br /> <br /> == CruiseControl ==<br /> * Once again, our project will have a focus on distributed testing and building.<br /> * Our support for C# technologies will be within our control if something goes wrong. Also, knowing how mono works on all platforms is much easier than knowing how both Java and Mono work on all platforms.<br /> <br /> == BuildBot ==<br /> * Buildbot has a great architecture for distributed builds and testing<br /> * We will not use Python is a configuration language, rather we will be using XML structures more similar in CruiseControl<br /> * We will have more direct support for C# technologies<br /> <br /> == Manual Building &amp; Testing ==<br /> * More efficient<br /> * More automated<br /> * More proven</div>

Daedius