Build Job Constraints

User Guide › Reference › Build Job Constraints

User Guide

Navigation←→

34 Build Job Constraints #

34.1 hostlabel
34.2 sandbox
34.3 linux
34.4 hardware
34.5 Constraint Handling
34.6 Checking Constraints with osc

Build job constraints can define requirements for the hardware or software of the build host. Constraints can be defined per package or for repositories.

The build constraints for an entire project or specific repositories is part of the project config. For each constraint, it contains a line

Constraint: <SELECTOR> <STRING>

The selector is a colon-separated list.

The build constraints for a package are part of the package sources, as a _constraints XML source file (validated on submission). The _constraints source file can contain the values listed below.

In addition to that some build recipe parsers support to parse constraints also from the build descriptions, eg. in spec files. These can also be used conditionally in their context. For example to apply these only on some architectures or only for specific multibuild flavors.

Constraints defined in project build config, _constraints and the build recipe are merged in this order. This means a constraint for the same topic overwrites the one from the former location.

NOTE: If no build host meets the constraints, the package will turn to a failed state.

34.1 `hostlabel` #

The hostlabel is any string which can be assigned to build hosts when starting the bs_worker process. It can be used to run on specific hosts, which may be used for running benchmarks in a reproducible way. This constraint can also be defined as a negative definition using the exclude=true attribute. However, the hostlabel is always specific to one OBS instance. You should avoid it as much as possible, since building with this constraint in another instance is usually not possible. Use any of the other constraints if possible.

Example for _constraints file:

<constraints exclude="false">
  <hostlabel>benchmark_runner</hostlabel>
</constraints>

Example for project configuration:

Constraint: hostlabel benchmark_runner

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hostlabel benchmark_runner

34.2 `sandbox` #

Defines the sandbox which is used for the build job. Sandboxes are chroot, Xen or KVM environments. There is also the virtual secure sandbox, which allows building on Xen or KVM. This constraints may also be defined as a negative definition via the exclude=true attribute.

Example for _constraints file:

<constraints exclude="true">
  <sandbox>secure</sandbox>
</constraints>

Example for project configuration:

Constraint: sandbox secure

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hostlabel:benchmark_runner

34.3 `linux` #

The Linux kernel specific part.

34.3.1 version #

To require a specific Linux kernel version.

Example for _constraints file:

<constraints>
  <linux><version>
    <min>3.0</min>
    <max>4.0</max>
  </version></linux>
</constraints>

Example for project configuration:

Constraint: linux:version:min 3.0
Constraint: linux:version:max 4.0

Example for rpm spec file or Dockerfile:

#!BuildConstraint: linux:version:min 3.0
#!BuildConstraint: linux:version:max 4.0

34.3.1.1 `min` #

Minimal kernel version.

34.3.1.2 `max` #

Maximal kernel version.

34.3.2 `flavor` #

A specific kernel flavor like default or smp (from kernel packages kernel-default or kernel-smp).

Example for _constraints file:

<constraints>
  <linux>
    <flavor>default</flavor>
  </linux>
</constraints>

Example for project configuration:

Constraint: linux:flavor default

Example for rpm spec file or Dockerfile:

#!BuildConstraint: linux:flavor default

34.4 `hardware` #

To require hardware or build instance features.

34.4.1 `cpu` #

To require a specific CPU feature.

34.4.1.1 `flag` #

CPU features which are provided by the hardware. On Linux they can be found in /proc/cpuinfo. The flag element may be used multiple times to require multiple CPU features.

Example for _constraints file:

<constraints>
  <hardware><cpu>
    <flag>mmx</flag>
    <flag>sse2</flag>
  </cpu></hardware>
</constraints>

Example for project configuration:

Constraint: hardware:cpu:flag mmx
Constraint: hardware:cpu:flag sse2

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hardware:cpu:flag mmx
#!BuildConstraint: hardware:cpu:flag sse2

EL0 is a special flag that that can be used on hardware that only supports level-0 exceptions, such as certain armv8l systems. This means that VMs or 32-bit kernels are not supported but userland is supported. This flag can be used to block builds on such hardware if no 64-bit kernel is available for a project.

Example for project configuration:

Constraint: hardware:cpu:flag exclude=true EL0

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hardware:cpu:flag exclude=true EL0

Additional flags are also reported for effective architecture level of the cpu. This includes the following flags:

power7
power8
power9
x86-64-v2
x86-64-v3
x86-64-v4

34.4.2 `processors` #

To require a minimal number of processors provided by the VM.

Example for _constraints file:

<constraints>
  <hardware>
    <processors>4</processors>
  </hardware>
</constraints>

Example for project configuration:

Constraint: hardware:processors 4

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hardware:processors 4

34.4.3 `jobs` #

To require a minimal number of pre-confiured parallel jobs for the build job. This limits the parallel wanted jobs for the build tooling, but is actually not a hardware requirement.

Example for _constraints file:

<constraints>
  <hardware>
    <jobs>4</jobs>
  </hardware>
</constraints>

Example for project configuration:

Constraint: hardware:jobs 4

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hardware:jobs 4

34.4.4 `disk` #

Hard disk specific.

34.4.4.1 `size` #

To require a minimal size of the disk.

Example for _constraints file:

<constraints>
  <hardware>
    <disk>
      <size unit="G">4</size>
    </disk>
  </hardware>
</constraints>

Example for project configuration:

Constraint: hardware:disk:size unit=G 4

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hardware:disk:size unit=G 4

34.4.5 `memory` #

Memory specific.

34.4.5.1 `size` #

To require a minimal memory size including swap space.

Example for _constraints file:

<constraints>
  <hardware>
    <memory>
      <size unit="M">1400</size>
    </memory>
  </hardware>
</constraints>

Example for project configuration:

Constraint: hardware:memory:size unit=M 1400

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hardware:memory:size unit=M 1400

34.4.6 `physicalmemory` #

Memory specific.

34.4.6.1 `size` #

To require a minimal memory size. Swap space is not taken into account here.

Example for _constraints file:

<constraints>
  <hardware>
    <physicalmemory>
      <size unit=M>1400</size>
    </physicalmemory>
  </hardware>
</constraints>

Example for project configuration:

Constraint: hardware:physicalmemory:size unit=M 1400

Example for rpm spec file or Dockerfile:

#!BuildConstraint: hardware:physicalmemory:size unit=M 1400

34.5 Constraint Handling #

The constraint handling depends on what is met by the restrictions. The handling starts when there is no worker to fulfill the constraints.

34.5.1 More than half of the workers satisfy the constraints #

The job will just stay in state scheduled and no further notification is set.

34.5.2 Less than Half of the Workers Satisfy the Constraints #

The job will stay in state scheduled and the dispatch details are set to tell the user that this job can take a long time to be built. This will be shown in the Web UI on mouse over and the scheduled state will be highlighted as well.

waiting for 4 compliant workers (4 down)

The (4 down) means that 4 of the 4 compliant workers are down and that someone should have a look.

34.5.3 No Workers Satisfy the Constraints #

If no worker can handle the constraints defined by the package or project the build job fails. There is also a hint in the build log what has failed.

package build was not possible:

no compliant workers (constraints mismatch hint: hardware:processors sandbox)

Please adapt your constraints.

34.6 Checking Constraints with `osc` #

You can check the constraints of a project / package with the osc tool. You have to be in an osc working directory.

osc checkconstraints [OPTS] REPOSITORY ARCH CONSTRAINTSFILE

Either you give a repository and an arch or osc will check the constraints for all repository / arch pairs for the package. A few examples:

# osc checkconstraints
Repository                Arch                      Worker
----------                ----                      ------
openSUSE_Leap_42.2        x86_64                    1
openSUSE_Leap_42.1        x86_64                    1

If no file is given it takes the local _constraints file. If this file does not exist or the --ignore-file switch is set only the project constraints are used.

# osc checkconstraints openSUSE_Leap_42.1 x86_64
Worker
------
x86_64:worker:1
x86_64:worker:2

If a repository and an arch is given a list of compliant workers is returned.

Another command to verify a worker and display the worker information is osc workerinfo.

<worker hostarch="x86_64" registerserver="http://localhost:5252" workerid="worker:1">
  <hostlabel>MY_WORKER_LABEL_1</hostlabel>
  <sandbox>chroot</sandbox>
  <linux>
    <version>4.1.34-33</version>
    <flavor>default</flavor>
  </linux>
  <hardware>
    <cpu>
      <flag>fpu</flag>
      <flag>vme</flag>
      <flag>de</flag>
    </cpu>
    <processors>2</processors>
    <jobs>1</jobs>
  </hardware>
</worker>

It returns the information of the desired worker.

Print this page

User Guide

34 Build Job Constraints #

34.1 hostlabel #

34.2 sandbox #

34.3 linux #

34.3.1 version #

34.3.1.1 min #

34.3.1.2 max #

34.3.2 flavor #

34.4 hardware #

34.4.1 cpu #

34.4.1.1 flag #

34.4.2 processors #

34.4.3 jobs #

34.4.4 disk #

34.4.4.1 size #

34.4.5 memory #

34.4.5.1 size #

34.4.6 physicalmemory #

34.4.6.1 size #

34.5 Constraint Handling #

34.5.1 More than half of the workers satisfy the constraints #

34.5.2 Less than Half of the Workers Satisfy the Constraints #

34.5.3 No Workers Satisfy the Constraints #

34.6 Checking Constraints with osc #

34.1 `hostlabel` #

34.2 `sandbox` #

34.3 `linux` #

34.3.1.1 `min` #

34.3.1.2 `max` #

34.3.2 `flavor` #

34.4 `hardware` #

34.4.1 `cpu` #

34.4.1.1 `flag` #

34.4.2 `processors` #

34.4.3 `jobs` #

34.4.4 `disk` #

34.4.4.1 `size` #

34.4.5 `memory` #

34.4.5.1 `size` #

34.4.6 `physicalmemory` #

34.4.6.1 `size` #

34.6 Checking Constraints with `osc` #