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

Merge remote-tracking branch 'origin/master' into check_source_fix_and_tests

Browse Source
This commit is contained in:
Josef Reidinger 2021-09-23 10:58:31 +02:00
commit ab2cf543ab
No known key found for this signature in database
GPG Key ID: 5795B05DBC562F48
2 changed files with 1 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
dist/ci/testenv-tumbleweed/Dockerfile vendored
View File

@ -10,7 +10,7 @@ RUN zypper in -y osc python3-pytest python3-httpretty python3-pyxdg python3-PyYA
python3-influxdb python3-pytest-cov python3-coveralls libxml2-tools curl python3-flake8 \
shadow vim vim-data strace git sudo patch openSUSE-release openSUSE-release-ftp \
perl-Net-SSLeay perl-Text-Diff perl-XML-Simple perl-XML-Parser build \
obs-service-download_files
obs-service-download_files obs-service-format_spec_file
RUN useradd tester -d /code/tests/home
COPY run_as_tester /usr/bin

48
docs/processes.md
View File

@ -42,54 +42,6 @@ This [testcase](../tests/factory_submit_request_tests.py) showcases the whole su
explaining how the different reviews are created and processed by OBS and by the involved bots and
release tools.
### Rings and Staging Projects
As said before, Factory contains a huge amount of packages. The project receives a lot of new
request all the time. These requests have to be reviewed, adjusted and tested before being accepted.
Reviewing all these packages one by one would be almost impossible. Moreover, some changes in a
package could conflict with other packages. Rings and Staging Projects help to deal with these
problems, making the review and testing processes more efficient.
[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. 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 Manager (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/she 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 needed 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, 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
The SUSE Linux Enterprise distribution is built in a SUSE-internal instance of OBS usually referred