本页面，主要描述了ros，ros-pkg，wg-ros-pkg代码仓库的测试，当然其他的仓库也可以加到Hudson。如果你有兴趣通过“代码构建场(build farm)”把自己的相关仓库包加进来测试，请发邮件给ros-users

It is important to keep builds of the tree in a working state as much as possible. The Hudson-based build farm performs automated builds and tests on a variety of platforms, and can help with this, but only help if we are all committed to this goal.

SIMULATOR TESTS

• John and Tony have set up a collection of quad-core machines running Gazebo, and updated Hudson to continuously check out, build, and run tests in the simulator.
• The test suite currently covers use of the robot for navigation and doors, and is growing to exercise more of the full system
• If these tests break, that means the build is broken.

EXPECTATIONS IF YOU BREAK THE BUILD

• The build is considered broken if either compilation or any tests fail.
• If you break the build, fix it again quickly (either by resolving it, or by rolling back your change until the problem can be resolved). When the build stays broken, it becomes much more difficult to catch other regressions, and problems can build up.
• It is the responsibility of anyone making a change to make sure it propagates through the system, so even if a breakage looks unrelated to your commit, take the time to look into it enough to be sure or coordinate with the other people on the email to make sure someone istaking action on it.
• If a breaking commit is not being resolved quickly, it may be rolled back by someone else on the team, but hopefully this is a situation we will be able to avoid.

WHEN MAKING CHANGES

* Partial or interim commits that break the build temporarily are not an OK way to make major changes. Either develop on a branch and merge atomically, or make a change with backwards compatibility and don't break old functionality until the tree is all fixed.

• Especially with major changes, make sure you'll be available to respond to the output of the automated build if there's a problem.
• If the build is broken, especially in areas related to your changes, the problems should get fixed before you check in other major changes. To achieve this, coordinate with the people who seem to have broken it, fix the problem yourself, or if necessary revert the prior changes.

---