openQA bites

This blog post ist about uploading a custom VM disk image to the Azure cloud and create a VM to boot from this image.

If you just want to upload a image, checkout the az_upload_img bash script at the very end of this post for a easy-to-use script without the need to dive into details.

Then using openqa-clone-job (and derivates) one can use the SCHEDULE variable to clone a test run with a custom set of test modules. This is particular useful, when developing a new test case and you need a verification run with e.g. an additional test module or to exclude some failing ones. However it is sometimes cumbersome to type out a large list of tests into a custom SCHEDULE variable, if the amount of test modules exceeds 5 or more tests (e.g. extra_tests_textmode - good luck!).

In this encore to the Run Azure images in Hyper-V or kvm will briefly discuss, if it is possible to create your own Hyper-V Windows Hypervisor as a kvm guest on openSUSE Tumbleweed.

Disclaimer: This blog post is about SUSE Linux Enterprise Server images on Azure and probably only useful to SUSE Employees who work with such images.

Today I’d like to point out an amazing new tool: The Container Layer Analyzer, written by Dan Čermák. Dan also wrote a comprehensive blog post about it, which explains it much better than what I do here.

In this blog post I present you a small script, which can help you to remove empty job groups from your own openQA instance. This is helpful if you have a development instance with a lot of job groups, that you never use. This script can help you to tidy the list of dangling job groups.

Today we are going to play a bit around with the amazing API that every openQA instance provides. The aim of this tutorial is to show how the API can be accessed using a simple language like python. More advanced topics like job posting, deletion and other methods that require authentication are possible but not covered extensively in this post. The reference for this post will be openqa.opensuse.org, but everything works pretty much with every openQA instance.

Checkout the new openqa-cli cheat sheet page where I start to collect some useful “how do I do …” snippets for the openQA CLI utility openqa-cli.

When dealing with go modules, sometimes it’s handy to test some changes from a local repository instead of using the upstream one.

Now, go programs are typically relying only on the upstream packages. Take the module file of openqa-mon as example:

pasta is a stupid simple pastebin service for self-hosting. I started this project months ago because I was missing an easy, simple and no pain self-hosting solution. This is what pasta is about. You just throw a file at it via it’s archaic web interface, a simple POST request or with its stupid simple CLI tool: