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 <seb@highlab.com> if you want access.

If you want to look around the auto-build debian archive, go to the dists/ directory.

Build details

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:

• First we build and run the test suite on all supported platforms (sim and realtime on all supported distros and architectures). These builds are done on machines installed using a process very similar to the one recommended for our users, with the addition of the standard development tools (gcc, dpkg-dev, etc). Early in the build process, the debian/control file is inspected (using dpkg-checkbuilddeps) and any missing build dependencies are installed (using apt-get). New build-time dependencies that are not listed in debian/control (or that are not available on all our build platforms) will cause a build failure here!
• If the tests pass on all our supported platforms a second set of builds is done, this time to make debian packages. These builds are done using pbuilder, a chroot build tool designed for this specific purpose. This chroot starts out as a minimal install, and then installs only the packages explicitly requested by the source package being built. The resulting debs are uploaded to the proper places in our debian archive.

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.

General info

If you want to help by running a buildslave, start by reading the Buildslave Admin Guide.