Cross-posting. This should be interesting to both sides. At the end of the mail there is a small glossary, since I assume some readers will not be familiar with some of the used terms. Since we (the YaST team) plan to implement the writing openQA tests into our regular development workflow, Imo and me have spent the last couples of days playing with openQA and our current development tools. We are not interested in the iso-oriented approach used at openqa.suse.de and openqa.opensuse.org. We want to run single jobs for the code we are developing right now. There are 2 kind of jobs we want to run: testing the installation and testing a YaST module (like any other application). 1) Testing the installation If we introduce these changes (or very similar ones) in openQA[1], we will be able to generate a DUD, submit it to the openQA host and execute a single job to run the installation including our changes. We already applied the process successfully[2] and we already have rake tasks that automate the whole process. [1] https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/460 https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/461 https://gitlab.suse.de/openqa/os-autoinst-needles-sles/merge_requests/4 [2] https://dhcp78.suse.cz/tests/12 https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/462 2) Testing the applications The DUD approach proved to be very useful for installation and we think can be applied to applications as well. I already have an special distri that takes an already installed system, boots it, applies all the updates from the YaST:Head repo and then run a list of application tests. My plan is to modify it to support installing packages from an uploaded DUD, as the installation already does. We could share the needles repositories of openSUSE/SLE and have all the application tests in a specific directory, so the mechanism for sharing code and needles will be very similar to the one already used for SLE and openSUSE. Most of the rake tasks would be completely reused. Generating and refreshing the installed systems (an asset) used as starting point for these jobs can be easily automated thanks to PUBLISH_HDD, as you can see here[3]. The test proving that the new distri works were lost in a recent hard disk accident, but they will be available today again [3] https://dhcp78.suse.cz/tests/1 So we already have all the pieces and our first installation test (test module to be precise) for a functionality still on development. Let's open the discussion! Cheers. And now the glossary: DUD - ftp://ftp.suse.com/pub/people/hvogel/Update-Media-HOWTO/Update-Media-HOWTO.html The most convenient way to deliver updates to the system (including the installer) in a file or cd image. asset - The elements used to feed the openQA jobs. Can be an ISO, a hard disk image or a repository. They can be registered manually (like our rake tasks do) or generated by another job (like in [3] that generates the installed system to be used in other tests). rake - https://github.com/ruby/rake The tool the YaST team uses to automate the development work. distri - A set of tests in openQA. It defines the steps (a.k.a. test modules), in which order the steps are run and how to react to some environment variables. We have a separate distri for openSUSE and SLE, although they share the definition of the steps (modules). -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org