On 05/27/2015 09:48 AM, Josef Reidinger wrote:
On Wed, 27 May 2015 09:43:26 +0200 Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Am 27.05.2015 um 09:16 schrieb Ancor Gonzalez Sosa:
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).
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@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org