LinuxCNC Buildbot Developer Info
Results from recent builds
Compile and test results: http://buildbot.linuxcnc.org/buildbot/waterfall
Auto-built docs from recent builds: http://buildbot.linuxcnc.org/doc
Clang analysis of recent builds: http://buildbot.linuxcnc.org/clang
We also do occasional runs through Coverity's static analyser via their excellent Scan program. Contact Sebastian Kuzminsky <email@example.com> if you want access.
If you want to look around the auto-build debian archive, go to the dists/ directory.
All branches that are pushed to the linuxcnc.org git repo are built and tested by the buildbot. If a build is successfull, the build results (debs, docs, clang results, etc) are recorded in the places listed above.
Each "buildbot build" consists of many individual compile cycles, on many different build machines:
Sorting of packages and other build results
Debs from the official release branches are placed into the regular per-branch components within the Debian archive (as of this writing, the "official release branches" are v2.4_branch, v2.5_branch, and master, but see scripts/githelper.sh for the actual branch-name-to-deb-component mapping).
Debs from un-official branches (mostly short-lived experimental branches), are put in the "scratch" component. To access these debs, add one of these stanzas to your /etc/apt/sources.list.d/linuxcnc-buildbot.list (select the one appropriate for your distro):
deb http://buildbot.linuxcnc.org/ $DIST scratch-sim deb-src http://buildbot.linuxcnc.org/ $DIST scratch-sim
deb http://buildbot.linuxcnc.org/ $DIST scratch-rt deb-src http://buildbot.linuxcnc.org/ $DIST scratch-rt
Debugging failed builds
So you pushed something to the git repo (to master or to one of the stable release branches or to a private experimental branch), and something broke - the buildbot failed to compile your version. What went wrong?
Go to the waterfall page.
Find the "checkin" builder in the top row.
Search down the checkin builder's column to find your commit that triggered the build. The leftmost column of the waterfall page has a list of times that events have happened at. The next column to the right has a list of commits, showing the name of the developer who did the commit, and mouse-over shows the first line of the commit message. When a commit comes in, the checkin builder will finish whatever it's doing and when it's done and ready to do something new, will start a new build with any pending commits (this is on a per-branch basis, of course). So find the next checkin build to start after your commit (this build should be red, indicating that it failed), and click on the "Build $NUMBER" link in the build's bubble in the checkin builder's column.
On that build's page, in the "Steps and Logfiles" section, you can see all the builds that the checkin builder triggered (the checkin builder doesn't do any work itself, it just triggers other builders and examines their results). Some of these triggered builders will have failed. Click on the triggered builders to see how their build steps went. These may be green (indicating complete success), or yellow (indicating success but with warnings), or red (indicating failure).
When you find a "real" builder with a red build-step, click on that build-step's "stdio" link. It will show you the exact command that was run, the directory it ran in, the environment, and all the output. Down near the bottom should be the fatal error that aborted the build.
A developer's workflow using the buildbot for testing
If you're working on a new feature or a bug fix, you can use the buildbot to automate a bunch of your testing:
Do your work on a "private" branch based on the "official" branch you plan to push to when you're done. By doing your work on a semi-private unofficial branch, intermediate states of the branch that might not build on all platforms or might not work fully will not cause any trouble for other developers (or for users who follow the official branches on the buildbot), and will not pollute the history of our official branches.
When you're ready to test your branch, push it to the linuxcnc.org git repo. The buildbot will notice it and kick off a full build. Monitor the waterfall page and track down and fix any build failures and test failures.
Since this is a "private" branch, feel free to rebase at will to clean up your history. Push the rebased branch (with --force) to test it. Be careful to not force-push any rebased shared branches, especially official branches!
Once the branch is ready for inclusion into the official branch (after it passes all buildbot builds and tests, and maybe has been reviewed by other developers), rebase it on top of the target branch, re-test, and push (without --force!) to the official branch.
Once your private branch is merged into the official branch, delete the private branch from the central repo, just to keep things tidy.
If you want to help by running a buildslave, start by reading the Buildslave Admin Guide.