After having set up the typical things open source projects needs like a website/wiki, mailing-list and bug-tracker, Maliit now also has something not so common: a build-bot.
As Maliit consists of several components that can be built in several different ways (and for several different platforms), we wanted to automate the build and tests of the different variations to ensure that we do not break any of them. This is especially important for variations which are not easy to test for the individual developers, like for instance Maliit on Qt 5.
The software chosen to help with this task was Buildbot. Getting an initial instance it up and running was very quick and pain-free, especially thanks to packages being easily available and the excellent documentation. The current setup now builds, tests and installs the two major components we have: Maliit Framework and Maliit (Reference) Plugins, in the most important build/config variations we have. A total of 12 individual build jobs, plus 2 meta-builds. The configuration for the instance can be found in the maliit-buildbot-configuration repository.
For security reasons the build-bot is not directly exposed to the Internet. Instead a script runs every 5 minutes to generate a static HTML website and publish on the public web-server: Maliit build-bot
This gives us a minimal continuous integration system for Maliit, which for now will hopefully helps us avoid breakage. In the future, the usage of the build-bot might extend to include:
- Automating the release process
- Testing of merge-requests/patches before merging to master
- Automated integration/system testing, complementing the unit-tests
- Triggering external builders for packaging. OpenSUSE OBS, Maemo 5 Garage, etc.
- Automating certain aspects of bug-lifetime. Resolving when fix is committed, closing on release if pre-verified, etc
6 thoughts on “The Maliit buildbot”
Thanks for setting this up, and also thanks for not using Jenkins in the end 😉
That looks truly useful.
Is there a problem with the logs? It would be nice to see why builds fail. For instance, this does not show why the build failed:
@Murray: The builds are configured into a meta-build (triggered by git commits) which then triggers all other builds, with their different configurations. Your link points to such a meta-build, but somehow, there is no link to the other builds it triggered. It’s possible to see the relationship in the waterfall view though.
Michael, maybe there is somewhere you can file abug?
Sorry, I somehow missed these comments completely. Yes, it has already proven useful. While settings things up I already found and fixed several regressions in more rarely used build configurations, and we can now be significantly more confident that it does not happen again unnoticed.
The issue with logs on triggered/meta-builds is tracked here: https://bugs.maliit.org/show_bug.cgi?id=62. I am chasing up the guy now.