User:Bkabrda/BuildSys

BuildSys Specification and Analysis

General Use Case

1. User logs in using OpenId.
2. User creates a #PrivateRepo. POLICY: who can create a repo, how many repos?
3. User alters the repo settings (#MockConfig, #Permissions, TODO: anything else?) as he wishes.
4. User uploads a number of SRPMs and lets them build with specified mock config(s). In next versions, these will also be submitted from sort-of-dist-git or by automatical builds from gems/pypi/cpan.
5. When the build is finished, it's results are transferred to the PrivateRepo's #RepoHome.
6. Everyone can download the repofile (probably as an installable RPM containing just the yum repofile) and install packages from it.

Builds In PrivateRepos

Summary of build process in a #PrivateRepo instance.

1. One or more SRPMs have been submitted to build with one or more #MockConfigs. This results in a parent #Task.
   1. In future, the SRPMs may be also be built and submitted from "sort-of-dist" or provided by automatic conversion from Ruby Gems, etc.
2. BuildSys gets proper builders (proper system version, architecture) from a builder provider (cloud?).
3. BuildSys starts the builds (with mockchain/mockremote/...?) using specified #MockConfigs on the builders. This results into one or more sub#Tasks.
4. When the builds are finished (both successfully and unsuccessfully), results are transfered to the #RepoHome.
5. createrepo (=> new #Task) is run unless the builds were scratch or some of the builds failed.
6. The parent #Task ends here.

Terms, Definitions, Explanations

This section explains different terms and their meanings/functionality details.

PrivateRepo

The whole thing :)

• The repo has multiple #MockConfigs, e.g. fedora(/centos?) release and architecture.
• The repo has defined #Permissionss.

Permissions

POLICY: Each repo has only repo-level permissions. The permissions are be divided into these groups: repo-admin (specifies permissions of other users for the repo), repo-rel-eng (can add/modify/delete mock configs, trigger createrepo runs, delete old builds), repo-packager (can build packages, delete old builds). No package-level permissions are considered for first version.

MockConfig

A mock config inside a #PrivateRepo.

• A single mock config in a repo (this should in fact be a full mock config file as in /etc/mock). POLICY: Using different base repos should be forbidden. The users should only be allowed to configure additional repos. The base repo will serve as a fixed point for determining architecture and OS version.
• Each mock-config can be altered: adding more yum repos, altering minimal buildroot. To be prepared for sort-of-dist-git, we should have both SRPM build mock configs and RPM build mock configs. The first version should only use RPM build mock configs. When both are used (in later versions), they should come in pairs (e.g. each RPM build mock config should have an associated SRPM build mock config - or none, perhaps).

RepoHome

A machine serving as a storage for build results. Contains a yum repo, that holds packages for all the successful builds and logs (even for non-successful builds).

• POLICY: how long will we store the packages/logs?

Task

Analogy of Koji task, e.g. an overall build task (parent of multiple build tasks)/build/createrepo run. Tasks can have subtasks.

Class Diagram

Available as image (http://bkabrda.fedorapeople.org/buildsys/buildsys-2.jpg) or DIA project (http://bkabrda.fedorapeople.org/buildsys/buildsys-2.dia).

Others

Things To Consider

• Automatic builds of packages from rubygems/pypi/cpan - best approach probably be having an automatic checker (something like upstream release monitoring) that would monitor packages and create SRPMs, packagers would then just go through the automatically prepared SRPMs (adjust them) and let them build.
• Using #PrivateRepos instead getting new set of tags in Koji - would probably require "sort-of-dist-git" to be able to merge the changes easily between Fedora and BuildSys.

Problems/More Policy Issues

• Licensing of the RPM content
• Tracking RPM origin - may turn out very important when having issues with content licensing
  • RPMs should have their ?DB entry/special header? (don't know yet, that's why that is not in the class diagram) that would say:
  • SRPM for binary RPM
  • Origin info (who - userid; from where - SRPM upload or "sort-of-dist-git" or automatic build; some other info) for SRPM