Information on this page is currently talking about the testing state of the ros, ros-pkg, and wg-ros-pkg repositories, but other repositories can be added to Hudson. If you are interested in adding your repository to the set of code testing by the build farm, please email 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.

---