action #12804
closed[qe-core][functional][sles][opensuse][installation] Do more easy to debug tests by using chroot installations … or containers :)
0%
Description
why do we need to bootstrap a full installation and watch at the screen when the result is just that package dependencies can not be resolved? I think for this we should rather user jenkins and chroot installations. This might be more of an issue for generic "SUSE/openSUSE testing approach" but please don't just close this ticket but move it to this project or create one if we don't have that progress project so far.
further interesting references¶
https://jenkins.debian.net/view/All/job/g-i-installation_debian_sid_daily_lxde/
Updated by asmorodskyi almost 7 years ago
- Subject changed from Do more easy to debug tests by using chroot installations to [sles][opensuse][installation] Do more easy to debug tests by using chroot installations
Updated by okurz almost 6 years ago
- Subject changed from [sles][opensuse][installation] Do more easy to debug tests by using chroot installations to [functional][sles][opensuse][installation] Do more easy to debug tests by using chroot installations
- Target version set to future
Updated by okurz over 5 years ago
- Subject changed from [functional][sles][opensuse][installation] Do more easy to debug tests by using chroot installations to [functional][u][sles][opensuse][installation] Do more easy to debug tests by using chroot installations … or containers :)
I think by now containers are the way to go :)
Updated by okurz over 5 years ago
- Related to action #20246: [gsoc] Investigate/implement container-based backend added
Updated by okurz over 5 years ago
- Target version changed from future to Milestone 21
Shortly discussed with slindomansilla. What we think might be feasible and useful is to conduct one of the existing test modules from openQA scenarios like "textmode" within a container. This would fit in somewhere between tests in OBS like https://build.opensuse.org/project/show/home:okurz:test-packagehub and the openQA installation scenarios. The quickmost dirty approach is probably when we boot any existing (older, stable) OS disk image, install docker in there, pull the latest published image of the product to test, add more current repos with SUSEConnect/zypper, register, install and conduct a simple test. However, this sounds a bit wasteful as we would need to boot a VM to conduct a container based test within. I feel we really should use gitlab CI instead. Maybe one micro-app that listens to AMQP OBS events and on new publications of the products we test trigger a container based CI test in a gitlab project.
Updated by okurz over 5 years ago
- Target version changed from Milestone 21 to future
Updated by SLindoMansilla about 4 years ago
- Status changed from New to Workable
- Priority changed from Normal to Low
- Estimated time set to 42.00 h
Updated by tjyrinki_suse over 3 years ago
- Subject changed from [functional][u][sles][opensuse][installation] Do more easy to debug tests by using chroot installations … or containers :) to [qe-core][functional][sles][opensuse][installation] Do more easy to debug tests by using chroot installations … or containers :)
Updated by mgrifalconi 9 days ago
- Tags set to qecore-cleanup
- Status changed from Workable to Rejected
Like the idea of using containers when possible instead of full SLE installation. But when we sell the full SLE installation I feel like it should be fully tested. (Adding more containers test is a great idea, which I guess we have in public cloud squad).
Anyhow. This topic is rotting since 8 years. Please re-create one with updated info if you feel is still current