33 Scheduling and Dispatching #

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 assignment of a build job to a concrete build host (aka worker) is called dispatching.

33.1 Definition of a Build Process #

A build process is calculated and executed based on the following

The sources of a package defined which dependencies are required at build time. For example, BuildRequires lines in spec files defined which other packages must get installed to build a package
The project configuration of the package defines repositories and architectures to build for. In case other repositories are used as a base the configuration from there is also considered.
Dependencies of packages which are required are considered as well.
Constraints regarding the worker are considered. A package may require certain amount of resources or specific features to build. Check the constraints chapter for details. However, apart from this the build should be independent of the specific worker where the job gets dispatched to.

33.2 Scheduling Strategies #

The defaults have the goal of creating an always reproducible state. This may lead to more builds than practically necessary, but ensures that no hidden incompatibilities exist between packages and also that the same state can later be achieved again (with a subsequent rebuild of the same sources and configurations). This can also lead to multiple builds of the same package in the case of dependency loops.

In some setups this may not be wanted, so each repository can be configured differently. The usual options to modify the project meta configurations can be used to configure different strategies. For example using osc:

osc meta prj -e YOUR_PROJECT

A repository is configured as following by default, however only the name attribute is required to be set.

# Example <repository
    name="standard" rebuild="transitive" block="all" linkedbuild="off"> [...]
    </repository>

33.2.1 Build Trigger Setting #

The build trigger setting can be set via the "rebuild" attribute. Possible settings are

transitive: The default behavior, do a clean build of all dependant packages
direct: Just build the package with changed sources and direct dependant packages. But not indirect dependant packages.
local: Just build packages with changed sources.

Note

Note: You can run into dependency problems in case you select direct or local without noticing this in the build state. Your packages might not even be installable or have random runtime errors (like not starting up or crashing applications), even when they claim to be "succeeded". Also, you cannot be sure that you will be able to re-build them later. So never do an official shipment with this setting of a release. This knob is exposed to allow deliberate suppression of the strictly reproducible builds (for example, to limit burning CPU unnecessarily).

33.2.2 Block Mode #

Usually the build of a package gets blocked when a package required to build it is still building at the moment. The "block" attribute can modify this behaviour:

all: The default behavior, do not start the build if a dependant package is currently building.
local: Just care about packages in your project for the block mode.
never: Never set a package to blocked.

Note

When using something other than “all” you will have to deal with the following problems:

Intermediate builds can have dependency and runtime problems.
Your packages will get built more often, take more resources on the server side. As a result the dispatcher will rate your repository down.

33.2.3 Follow Project Links #

off: DEFAULT: do not build packages from project links
localdep: only build project linked packages if they depend on a local package result.
alldirect: build all packages from the linked projects. Indirectly linked projects get not build.
all: build all packages from direct and indirect linked projects

33.3 Release Number Handling #

Most build formats define a version and a release number. The version is usually defined by the upstream project, while the release number is handled by the distributor. In addtion to this Open Build Service differentiates between a source change counter (called check-in counter aka CI_CNT) and a build counter (BCNT). The check-in counter gets increased when any source change is done. The build counter gets increased when a build gets triggered due to any other reason than a source change.

The version and check-in counter are defined by the package source, while the build counter is stored per project, package, repository and architecture combination.

33.3.1 Build Counter Syncing via Architectures #

The default configuration is to sync build counters across all architectures for a given project, package and repository. This can only be changed by the OBS administrator.

33.3.2 Build Counter Syncing via multiple packages #

In some cases it is critical keep the build counter in sync via multiple packages. The old way to do so is to define a common bcntsynctag in package meta. The used string identifies the packages to be kept in sync. The package name is the default when no bcntsynctag exists. Please note that this affects always all flavors of a multibuild source.

The newer recommended way is to define these tags in the sources instead. These work also with git implementations and are more flexible.