- The buildbot can be found at http://buildbot.sirikata.com/.
- Start at the buildbot waterfall, which shows the build configurations horizontally and builds in chronological order (newest first) vertically. Newest builds are at the top, including in-progress builds.
- The waterfall lets you check the current build status of the tree (some may still be building, so you might need to wait to ensure the latest commits are functional). It's a good way to sanity check that pushing commits on top of current master will only result in errors due to your commits.
- All pushes to origin/master result in builds on the update builders.
- Nightly builds are performed starting at midnight Pacific time on the full builders. These always build all dependencies: they check that 'from scratch' builds are working.
- Additionally, documentation builds are performed nightly. The generated documentation is then automatically pushed to the web server.
There are two ways to test builds before pushing to master: try jobs and test branches.
Try jobs allow you to send a diff to the buildbot, which it applies on top of the most recent commits to the repository.
For this method, you need access to the buildbot server: it works by using ssh to upload the request. Ask Ewen for access.
- Install buildbot (first time only). Buildbot needs to do some work locally to generate the diff and communicate with the server, so you need it installed. Assuming your python and pip are up-to-date, the following should work:
sudo pip install buildbot
- Setup some configuration options so you don't have to pass them on the command line (first time only). Add the following to ~/.buildbot/options:
try_connect = 'ssh' try_vc = 'git' try_host = 'buildbot.sirikata.com' try_dir = '~sirikatabuildbot/master/try_jobdir' try_username = 'YOUR_USERNAME' try_builders = ["linux-update-build", "mac-update-build", "windowsxp-vc9-sp1-update-build" ]
The first two options are generic, just indicating the protocol and version control system. The next two specify the machine and request location. The username is the one you get on the buildbot host. Finally, the builders can be customized, but these are good defaults. They check all three platforms using full builds, which test all dependencies. Check the main buildbot page for the names of all builders if you want to customize this.
- Issue the try job, sending the diff build request to the server. In the Sirikata directory, first check the diff being submitted with the --dryrun option (-n is equivalent). Then, when satisfied, submit the job by removing that option. You may need to enter your password for your buildbot server account.
cd sirikata.git/ buildbot try --dryrun | less buildbot try
- Buildbot should be able to figure out the base revision (i.e. where to take the diff from) and the branch to use, but you can configure these with --baserev and --branch options if necessary.
- For more options, check the help:
buildbot try --help
An alternative to try jobs is to just push to the central repository on a branch and force a build. This is useful if you have a long-term branch you'll be developing on anyway.
You can control builds through IRC or the web interface. IRC is generally simpler since you can easily request multiple builders to build your branch and get notified when the build finishes.
- Push to origin on a new branch.
- Go to buildbot page.
- Find builder you want to test, e.g. linux-update-build, and click on it to see the builder page for it.
- On the right, under the 'Force build' section, enter your username, password, reason for build, and under 'Branch to build', fill in the branch you pushed to origin. Hit the 'Force Build' button.
- Wait on your build by checking the waterfall page or the builder page.
- Once your done with the branch, remember to clean it up!
git push origin :your_branch