diff --git a/dist/ci/testenv-tumbleweed/Dockerfile b/dist/ci/testenv-tumbleweed/Dockerfile index 669951fe..b3d6f989 100644 --- a/dist/ci/testenv-tumbleweed/Dockerfile +++ b/dist/ci/testenv-tumbleweed/Dockerfile @@ -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 diff --git a/docs/processes.md b/docs/processes.md index e7da7121..ac82c7dd 100644 --- a/docs/processes.md +++ b/docs/processes.md @@ -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