User:Bkabrda/BuildSys

BuildSys Specification and Analysis

General Use Case

1. User logs in using OpenId.
2. User creates a private repo. POLICY: who can create a repo, how many repos?
3. User alters the repo settings (#MockConfig, #Permissions, TODO) 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.
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 subtasks.
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/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 mock configs, e.g. fedora(/centos?) release and architecture.
• The repo has defined permissions.

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 mock config file as in /etc/mock).
• 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 either 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.