yudaike/openSUSE-release-tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document ADI projects

Browse Source
This commit is contained in:
José Iván López González 2021-09-06 10:47:04 +01:00
parent d02e309b66
commit 294f8db72d
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/processes.md
View File

@ -48,11 +48,13 @@ As said before, Factory contains a huge amount of packages. The project receives
[A ring](https://www.youtube.com/watch?v=K-wTVGqKFR8) is an OBS sub-project that links to certain set of packages from the parent project. The goal of a ring is to group essential packages in order to build a smaller testable image. The core of Factory is divided into [two rings (0-Bootstrap, 1-MinimalX)](https://build.opensuse.org/project/subprojects/openSUSE:Factory:Rings). The ring 0 contains packages that form the most basic, minimalist system that can compile itself. On top of that Ring 1 adds what is in the default installation of the two primary Desktops. All other packages are not part of a ring.
[A Staging Project](https://github.com/openSUSE/open-build-service/wiki/Staging-Workflow) is a copy of the original project, and it serves as a playground for testing a set of requests. When a submit request is done to a package that belongs to any of the rings, the request is automatically put in a backlog for the Staging Master to review and to assign it to a specific Staging Project. The Staging Manager selects some of the requests he considers they belong together and assigns the corresponding packages to the same Staging Project. This way, a group of packages is built in one go. Once the Staging Project gets built and tested, all the requests can be accepted and the changes merged into the target project.
[A Staging Project](https://github.com/openSUSE/open-build-service/wiki/Staging-Workflow) is a copy of the original project, and it serves as a playground for testing a set of requests. In Factory, [Staging Projects](https://build.opensuse.org/project/subprojects/openSUSE:Factory:Staging) are named with a letter (e.g., [Staging:A](https://build.opensuse.org/project/show/openSUSE:Factory:Staging:A), [Staging:B](https://build.opensuse.org/project/show/openSUSE:Factory:Staging:A), etc). When a submit request is done to a package that belongs to any of the rings, the request is automatically put in a backlog for the Staging Master (person in charge of Staging Projects) to review and to assign it to a specific Staging Project. The Staging Manager selects some of the requests he considers they belong together and assigns the corresponding packages to the same Staging Project. For example, it might be possible that other packages fail due to a submit request. In that case, those packages are added to the same staging project, so they are built against each other. Once the Staging Project gets built and tested, all the requests can be accepted and the changes merged into the target project.
The Staging Manager can create as many Staging Projects as he considers and can assign different selections of requests to each of them. It is still tedious solving the conflicts that appear between different Staging Projects, but being able to test a lot of packages in parallel is much more efficient than doing the same package by package.
An ISO installation image is generated for each Staging Project regularly, and this image is tested on openQA in order to verify those packages would not break the current Factory. Similarly, a testing image is generated from each ring. The whole Factory would be tested only if the openQA tests for the ring images success.
An ISO installation image is generated for each Staging Project regularly, and this image is tested on openQA in order to verify those packages would not break the current Factory. Similarly, a testing image is generated from each ring. The whole Factory would be tested only if the openQA tests for the ring images success, see [staging-report bot](https://github.com/openSUSE/openSUSE-release-tools/blob/master/staging-report.py).
There is another kind of Staging Projects: ADI Projects (ADI is an acronym of *Ad Interim*). These are temporary projects created for submit requests of packages that do not belong to any ring. The main differences with a regular staging project are: a) only packages contained on the ADI Project are built (inherited packages are not rebuilt) and b) only *buildability* is checked (no openQA tests). In Factory, ADI Projects are named with *:adi:NUMBER* instead of a letter (e.g., openSUSE:Factory:Staging:adi:12).
## SUSE Linux Enterprise Development