23 Build Process #

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.

23.1 Phases of a Build Process #

All sources and binaries which are hosted inside Open Build Service are organized in projects. Projects host sources inside of OBS packages. The sources are built according to the repository configuration inside of the project.

23.1.1 Preinstall Phase #

This phase depends on the type of the buildroot (building environment). OBS supports multiple types of build environments, for example:

chroot
Xen
KVM
Qemu

In the preinstall phase, the OBS Worker creates a small base system from the packages declared to be preinstalled (file system, coreutils, binutils, rpm/debutils, etc.). The tools installed in this phase must only provide the minimum functionality necessary to allow installing further packages. In addition it copies all necessary build requirements and the source into the base system.

23.1.2 Install Phase #

Depending on the chosen build environment, the worker may start a virtual machine, an emulator or just enter the build root. If this was successful, the install phase reinstalls all base packages from above and additionally all packages you have defined in your build recipe plus dependencies. After this phase the environment is ready to process the build recipe.

23.1.3 Package Build #

Depending on the type of package, the build environment executes different build commands, for example:

RPM-based distributions: rpmbuild
Debian-based distributions: dpkg-buildpackage
Arch Linux: pacman
Kiwi image: kiwi.

How the build continues depends on the quality and the type of your build recipe. In most cases, the source code will be compiled now and then be packed into the chosen package format.

To improve package quality, on RPM-based distributions there are additional checks provided via packages. A common toolchain for handling checks is for example rpmlint.

23.1.4 After the Build #

The generated packages are extracted from the build environment and transferred back to the server by the worker. The build result might be postprocessed by followup build jobs. Afterwards the resulting files may get signed.

23.2 Identify a build #

OBS is usually tagging each build with an identifier. This can be used to find the building OBS instance, the project, repository and exact source for a binary. This information is stored in some variable called DISTURL and is specified as obs://$OBS_INSTANCE/$PROJECT/$REPOSITORY/$SOURCE_REVISION-$PACKAGE(:$FLAVOR). Note that the final segment, :$FLAVOR, is optional and exists only for packages built using the multibuild feature. The source specified via the DISTURL can be accessed by pasting the URL into the search interface of the OBS web interface. Or use the command line tool to check it out:

# osc checkout $DISTURL

You need to go to the right OBS instance as this is not handled automatically yet.

23.2.1 Read DISTURL from an RPM #

RPM binaries contain the DISTURL as tag. It can be read from the rpm database for installed RPMs and also from the rpm binaries itself.

# rpm -q --qf '%{DISTRL}\n' $rpm

23.2.2 Read DISTURL from a container #

Containers store the DISTURL as label. You will see only the DISTURL from the highest layer via

# docker inspect --format '{{.Config.Labels}}' $image_id

The disturl is always set via the key 'org.openbuildservice.disturl'.