Mailinglist Archive: yast-devel (65 mails)

< Previous Next >
[yast-devel] YaST and openQA
  • From: Ancor Gonzalez Sosa <ancor@xxxxxxx>
  • Date: Wed, 27 May 2015 09:16:49 +0200
  • Message-id: <55656F61.8030106@suse.de>
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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >