# The trouble with Buildbot

DevFeed: [The trouble with Buildbot](<https://devfeed.tech/articles/the-trouble-with-buildbot-21552.md>)

Original publisher: [Read original article](<http://lackingrhoticity.blogspot.com/2010/05/trouble-with-buildbot.html>)

Author: Mark Seaborn (noreply@blogger.com)

Published: 2010-05-05T21:42:00Z

Content type: opinion

Language: en

Sources: [Mark Seaborn](<https://devfeed.tech/sources/mark-seaborn.md>)

Topics: [configuration](<https://devfeed.tech/topics/configuration.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [ci](<https://devfeed.tech/topics/ci.md>), [Script](<https://devfeed.tech/topics/script.md>), [Logging](<https://devfeed.tech/topics/logging.md>), [make](<https://devfeed.tech/topics/make.md>), [Ubuntu](<https://devfeed.tech/topics/ubuntu.md>)

Tags: [automated](<https://devfeed.tech/tags/automated.md>), [config](<https://devfeed.tech/tags/config.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [logging](<https://devfeed.tech/tags/logging.md>), [logs](<https://devfeed.tech/tags/logs.md>), [make](<https://devfeed.tech/tags/make.md>), [script](<https://devfeed.tech/tags/script.md>), [test](<https://devfeed.tech/tags/test.md>), [testing](<https://devfeed.tech/tags/testing.md>), [ubuntu](<https://devfeed.tech/tags/ubuntu.md>)

## AI overview

The article argues that complex Buildbot configurations are difficult to test and maintain outside Buildbot. It recommends moving build and test steps into version-controlled scripts, while noting that this reduces Buildbot's structured logging visibility.

## Source excerpt

The trouble with Buildbot is that it encourages you to put rules into a Buildbot-specific build configuration that is separate from the normal configuration files that you might use to build a project (configure scripts, makefiles, etc.). This is not a big problem if your Buildbot configuration is simple and just consists of, say, "svn up", "./configure", "make", "make test", and never changes. But it is a problem if your Buildbot configuration becomes non-trivial and ever has to be updated, because the Buildbot configuration cannot be tested outside of Buildbot. The last time I had to maintain a Buildbot setup, it was necessary to try out configuration changes directly on the Buildbot master. This doesn't work out well if multiple people are responsible for maintaining the setup! Whoever makes a change has to remember to check it in to version control after they've got it working, which of course doesn't always happen. It's a bit ironic that Buildbot is supposed to support automated testing but doesn't follow best practices for testing itself. There is a simple way around this though: Instead of putting those separate steps -- "./configure", "make", "make test" -- into the Buildbot config, put them into a script, check the script into version control, and have the Buildbot config run that script. Then the Buildbot config just consists of doing "svn up" and running the script. It is then possible to test changes to the script before checking it in. I've written scripts like this that go as far as debootstrapping a fresh Ubuntu chroot to run tests in, which ensures your package dependency list is up to date. Unfortunately, Buildbot's logging facilities don't encourage having a minimal Buildbot config. If you use a complicated Buildbot configuration with many Buildbot steps, Buildbot can display each step separately in its HTML-formatted logs. This means: you can see progress; you can see which steps have failed; you'd be able to see how long the steps take if Buildbo