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

19.1 How is a build process defined

A build process is calculated and executed based on the following

  • The sources of a package defined which dependencies are required at build time. eg. 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. Please 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.

19.2 Scheduling strategies

The defaults have the goal of creating an always reproducible state. This may lead to more builds then practically necessary, but ensures that no hidden incompabilities 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 in a different way. 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>

19.2.1 Build Trigger Setting

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

transitive

The default behaviour, do a clean build of all depending packages

direct

Just build the package with changed sources and direct depending packages. But not indirect depending packages.

local

Just build packages with changed sources.

Note
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 a 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).

19.2.2 Block Mode

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

all

The default behaviour, don't start the build if a depending package is currently building.

local

Just care about packages in your project for the block mode.

never

Never set a package to blocked.

Note
Note

Note: When using something else then "all" you will have to deal with a number of 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.

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

all

treat packages from project links like local packages

Print this page