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.
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.
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>
The build trigger setting can be set via the "rebuild" attribute. Possible settings are
The default behavior, do a clean build of all dependant packages
Just build the package with changed sources and direct dependant packages. But not indirect dependant packages.
Just build packages with changed sources.
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).
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:
The default behavior, do not start the build if a dependant package is currently building.
Just care about packages in your project for the block mode.
Never set a package to blocked.
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.
DEFAULT: do not build packages from project links
only build project linked packages if they depend on a local package result.
build all packages from the linked projects. Indirectly linked projects get not build.
build all packages from direct and indirect linked projects