Mailinglist Archive: yast-devel (65 mails)

< Previous Next >
[yast-devel] Re: [openqa] YaST and openQA
  • From: Ancor Gonzalez Sosa <ancor@xxxxxxx>
  • Date: Wed, 27 May 2015 09:56:37 +0200
  • Message-id: <>
On 05/27/2015 09:48 AM, Josef Reidinger wrote:
On Wed, 27 May 2015 09:43:26 +0200
Ludwig Nussel <ludwig.nussel@xxxxxxx> wrote:

Am 27.05.2015 um 09:16 schrieb Ancor Gonzalez Sosa:
We are not interested in the iso-oriented approach used at and 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).

What about linking e.g. the Core DVD into YaST:Head, sync the built
iso to openQA and use the normal job templates? No need for DUD then.
That would also already reveal issues in case installation-images
needs to be adjusted for YaST changes.

I am not sure how situation looks now, but we try similar approach when
we convert YaST from ycp to ruby to ensure installer works in ruby and
problem is quite often, that changes in factory and yast itself cause
that DVD almost never built and sometimes it is less then once per day.
Maybe now with staging when factory gets packages in groups, rebuild is
not so often.

Generating and uploading the DUD is a piece of cake and takes just a few
seconds (verified). Quite convenient during development. In addition, it
can be done using a local openQA installation, so the process is totally
local and cheap.

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

Something like that is also required by maintenance QA. We need to
think which mechanisms to support that scenario can be made generic
and built into openQA.

I think simple devel repo and running `zypper dup -r <repo>` should do
all we needed, as we want to also test pre and post install scripts.

The advantage of using DUD in this scenario is that is more
self-contained. You upload the DUD to openQA and you use it during the
openQA job execution. No need to upload anything to a real repo (that
needs to be hosted somewhere), can be used with locally generated (and
totally experimental) packages, it's consistent over time if you restart
the job as long as you don't change the asset containing the DUD...

Ancor González Sosa
YaST Team at SUSE Linux GmbH
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >