One of the more important parts of the CI system is ensuring the correct dependencies are provided to a project to allow it to be successfully built. This article solely concerns KDE software as all other software is considered to be part of the Platform.
The first step in this process is for the CI system to determine what dependencies it needs to make available for a project. Because the CI system has to be able to resolve dependencies recursively, and needs to be able to use these dependencies to construct a build order for jobs, it is not possible for the system to rely on the build system itself for this information. Instead, it relies on files within the kde-build-metadata repository to determine the dependencies for a project.
These files contain a series of rules which specify which projects depend on which projects. In the below example, the rules specify that Zanshin depends on the krunner and kwallet frameworks, as well as akonadi-notes from KDE PIM.
playground/pim/zanshin: frameworks/krunner playground/pim/zanshin: frameworks/kwallet playground/pim/zanshin: kde/pim/akonadi-notes
These rules are evaluated recursively by the CI system to determine the final complete list of dependencies the system needs to provide (for the above example, the dependencies of krunner, kwallet and akonadi-notes would all be included as well).
Once the system has determined the complete list of dependencies it needs to provide it goes about retrieving the last successful installation of each of these projects. These installations are stored as part of the Capturing Installation step of each job and then stored in archives which can be found in the CI Artifacts Store. Successful installations are separated on the basis of Product, Platform and Branch Group to ensure incompatible binaries are not mixed together.
For dependencies that are not part of the Product, these are provided by special Dependency Build jobs which are rebuilt once a week. If projects within a Product have a dependency on regular changes in another project which is outside that Product, then the other project should be added to the Product.
Once retrieved, all of the dependencies are unpacked into a single directory and a series of environment variables are setup to ensure the resources within are able to be used as part of the build and testing process. These environment variables are: