Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
User Guide › Reference › Build Process
ContentsContents
User Guide
  1. About this Guide
  2. I First Steps
    1. 1 Beginnerʼs Guide
  3. II Concepts
    1. 2 Supported Build Recipes and Package Formats
  4. III Setup
    1. 3 osc, the Command Line Tool
    2. 4 Build Configuration
  5. IV Usage
    1. 5 Basic OBS Workflow
    2. 6 Local Building
    3. 7 Using Source Services
    4. 8 SCM/CI Workflow Integration
    5. 9 Staging Workflow
    6. 10 Notifications
    7. 11 Moderation
  6. V Best Practices
    1. 12 Using the OBS Web UI
    2. 13 Basic Concepts and Work Styles
    3. 14 How to integrate external SCM sources
    4. 15 Publishing Upstream Binaries
    5. 16 Bootstrapping
    6. 17 osc Example Commands
    7. 18 Advanced Project Setups
    8. 19 Building Kernel Modules
    9. 20 Common Questions and Solutions
  7. VI Reference
    1. 21 OBS Architecture
    2. 22 OBS Concepts
    3. 23 Build Process
    4. 24 Build Containers
    5. 25 Source Management
    6. 26 SCM Bridge
    7. 27 Supported Formats
    8. 28 Request And Review System
    9. 29 Image Templates
    10. 30 Multiple Build Description File Handling
    11. 31 Maintenance Support
    12. 32 Binary Package Tracking
    13. 33 Administration
    14. 34 Scheduling and Dispatching
    15. 35 Build Constraints
    16. 36 Building Preinstall Images
    17. 37 Authorization
    18. 38 Quality Assurance(QA) Hooks
    19. 39 openSUSE Factory
  8. Glossary
  9. A GNU Licenses
Navigation←→
User Guide › Reference › Build Process
Top
←→

23 Build Process

23.1 Phases of a Build Process
23.2 Identify a build

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'.

→Chapter 24 Build Containers←Chapter 22 OBS Concepts
Print this page

© 2024 SUSE