From Fedora Project Wiki
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
= BuildSys Analysis = | = BuildSys Analysis = | ||
== Use | == General Use Case == | ||
# User logs in using OpenId. | # User logs in using OpenId. | ||
# User creates a [[#PrivateRepo|private repo]]. POLICY: who can create a repo, how many repos? | # User creates a [[#PrivateRepo|private repo]]. POLICY: who can create a repo, how many repos? | ||
# User alters the repo settings ([[#MockConfig]], [[#Permissions]], TODO) as he wishes. | # User alters the repo settings ([[#MockConfig]], [[#Permissions]], TODO) as he wishes. | ||
# 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. | # 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. | ||
# When the build is finished, it's results are transferred to the PrivateRepo's [[#RepoHome]]. | # When the build is finished, it's results are transferred to the PrivateRepo's [[#RepoHome]]. | ||
# Everyone can download the repofile (probably as an installable RPM containing just the yum repofile) and install packages from it. | |||
| Line 19: | Line 20: | ||
=== 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), repo-packager (can build packages, delete old builds). No package-level permissions are considered for first version. | 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 === | === MockConfig === | ||
| Line 29: | Line 30: | ||
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). | 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? | * POLICY: how long will we store the packages/logs? | ||
== Builds In PrivateRepos == | |||
Revision as of 08:38, 10 September 2012
BuildSys Analysis
General Use Case
- User logs in using OpenId.
- User creates a private repo. POLICY: who can create a repo, how many repos?
- User alters the repo settings (#MockConfig, #Permissions, TODO) as he wishes.
- 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.
- When the build is finished, it's results are transferred to the PrivateRepo's #RepoHome.
- Everyone can download the repofile (probably as an installable RPM containing just the yum repofile) and install packages from it.
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?