We describe here the high-level concepts: how Open Build Service is designed, manages its content and is supposed to work.
The build process creates new binaries from sources, binaries, and config. This process may run on the OBS server side or on a local workstation. Each package build is created in a fresh environment. This is done to ensure that the environment is reproducible.
OBS is adding information to each created package about the origin of
the sources. This information is stored in the DISTURL
tag of an rpm, which can be displayed as follows:
The SCM bridge allows to setup single packages or entire projects in any trusted SCM repositories. However, the only supported SCM is currently git.
Open Build Service is by design format agnostic, but it needs format specific support to be able to parse build descriptions and running the build. This chapter is focusing on describing Open Build Service specifics of a format. Either limitations or extensions of Open Build Service builds.
The OBS comes with a generic request system where one party can ask another to complete a certain action. This can be, for example, taking source changes, granting maintainer rights or deleting a package. Requests are also used deal with more complex workflows.
Image templates are pre-configured image configurations. The image templates page provides a list of these templates. Users can clone these templates and further configure them as they like.
A package source may contain multiple build description files. They can be used depending on the base distribution, the repository name or for different configurations. These mechanics can be also combined.
This chapter explains the setup and workflow of a maintenance update in the openSUSE way. However, this should not be limited to openSUSE distribution projects but be usable anywhere (the entire workflow or just parts of it).
Products and updates to them are often officially supported by a company. To allow giving such support, there is binary package tracking. This feature allows checking which exact version of a package was shipped at what time. This feature is often important for release managers, maintenance engineer…
This chapter describes the components of an OBS installation and the typical administration tasks for an OBS administrator.
One of the major functionalities of OBS is to calculate always the current state, based on available sources, binaries and user configurations. In case a change happened it will trigger builds to achieve a clean state again. The calculation of the need of a build job is called scheduling here. The a…
Build job constraints can define requirements for the hardware or software of the build host. Constraints can be defined per package or for repositories.
Preinstall images can optionally be used to install a set of packages in one quick step instead via single package installations. Depending on the build host even snapshots with copy-on-write support may be used which avoids any IO.
Each package is signed with a PGP key to allow checking its integrity on user's machines.
OBS provides multiple hooks to place automated or manual tests at different points of time.
This chapter describes how the development of the future openSUSE distribution is done within OBS.