Hydra Build Server

From LSDevLinux
(Redirected from Packaging and testing)
Jump to: navigation, search

There are a number of SIL-related projects which benefit from having an organized way of being packaged and tested for multiple Linux distributions, including current and previous releases for both 32- and 64-bit architectures.

The way we have chosen to do this is to host each system as a vserver guest on a single physical machine. (VServer is more like an advanced chroot than a virtual machine, and is faster and closer to the physical hardware than other kinds of virtualization.) A script can build packages for each platform by invoking each guest's package-building process. Developers can also log in to experience and test their software on any of the supported platforms without having to set up such a machine themselves.

Hydra, our multi-headed monster, named for its many guests on one base machine, is set up to host these guests.

Guest machines in vserver

The plan is to run many systems in a vserver on the Hydra server.

We would like to distribute packages for

  • Different distributions: Ubuntu, openSUSE, Fedora, Debian
  • Both 32- and 64-bit architectures
  • Different releases: current, previous, and current LTS or equivalent

Hydra will host guests of each permutation of the above three things. (eg 4 * 2 * 2.25 = 18 machines)

Hydra vserver structure.png

Automation of packaging, testing

Some scripts will kick off package building and perhaps testing on each guest when desired and publish the packages to a web page. This could be just at release time, daily, or when desired.

Hydra will not function as a publicly-accessible package repository. packages.sil.org will continue to be the main repository for SIL-related packages. When finished and tested, packages will be uploaded to packages.sil.org and made available for general use.

Manual testing

When a developer wants to know how their software works on a certain distribution, release, architecture, or perhaps different desktop environment, all in a clean system or with certain modifications, it would be good to give them the ability to log into a guest and test their software.

This will need some coordination of user accounts and passwords/keys.

See also