The Unity Linux Build Server
The developers at Unity Linux have been working hard on expanding our package repositories. At this point, there are well over 8600 packages for each of the i586 and x86_64 architectures. Considering that our development team is still relatively small, this is quite a feat. One reason for this accomplishment is the establishment of standard procedures for building the RPMs, adding them to our repository, and promoting packages from unstable/test channels to the packages’ intended channels upon successful testing. The added benefit of this process is that it is very easy for new packagers and contributors to add content to Unity Linux. However, ensuring that every packager follows the standard build procedures has been somewhat difficult … until now.
The Unity Linux Build Server
One of the new additions to the Unity Linux packaging process is the introduction of the Build Server (or buildserv for short) The main purpose of the buildserv is to provide users with the ability to package content following our established procedures without being burdened by the overhead of doing so. The buildserv really consists of two parts: a backend server and a frontend web interface.
How Does It Work?
The frontend is a secure web interface to our standard build environment. Once an account is created for the packager, they can log into the buildserv and, with a few simple clicks, be able to select any of the packages they have recently committed to SVN, and schedule them for building. The actual RPM building happens by the backend server which processes the queued up requests. With the help of our chroot-based standard build environments it generates the i586 and x86_64 arch RPMs automatically. The success or failure of this build, as well as the details of the output are then accessible to the user from the web frontend.
This takes care of the initial packaging aspects of the buildserv. However, the full capability of the build server is far from over. If the RPMs for the requested package(s) were successfully created, the backend server then automatically transfers the files into the Test channel of our repos and cleans up any duplicate/obsoleted RPMs. Moreover, the buildserv can then promote these RPMs from the Test channel to the intended channel once the RPMs are deemed stable and tested*. In other words, much of the burden of tedious maintenance of packages while they are in the repos is removed from the shoulders of contributors, freeing them up to do more useful work.
Why Is the Buildserv Important?
Anytime you automate tasks there are benefits to those users and developers who would normally perform those tasks manually. In this case, the Unity Linux developers and contributors will save the tedious tasks of RPM building by the automated buildserv. In other words, packagers will be able to package more because of a huge time saving. This also could translate to more RPMs and packages for end users as developers may take on more packages due to the automation. When end users request a package it will be a few clicks of the mouse to get it into testing. This is a huge benefit for developers which is passed directly to end users through time savings.
The future of buildserv
There is still much work to be done on the buildserv. Currently, many of the administrative tasks cannot be done over the web interface (will only be available for users with admin privileges); the web interface itself, was done with quite primitive HTML and can use a modernized face lift; the frontend can use more cross-linking to improve usability; the backend still needs to be improved for synchronization with our repo content; the backend needs to be made PLF aware; etc.
There are many more features and improvements that will happen soon. Nevertheless, the build server is already gaining momentum and is on track to becoming the next big hit for Unity Linux.
* This capability is currently being worked on and is not yet fully functional.