openQA Package Testing
a project by RBrownSUSE
Updated over 6 years ago. 13 hacker ♥️. 1 follower.

openQA has a well earned reputation as a 'full system' testing tool, able to test a system end-to-end from the operating system to it's applications on a number of different platforms and architectures, including VM's & Bare Metal.

But one area of weakness is it's usefulness as a testing tool for developers or packagers. openQA can easily test a package once it's INSIDE a distribution, but how do you test that package BEFORE submitting it to the distribution?

openSUSE/SLE has the concept of 'staging', where we utilise OBS and openQA to basically create 'what-if' builds's for the whole OS where we can do basic validation tests to ensure a proposed check-in doesn't break the OS or it's basic functionality, but staging doesn't test the package itself

This hackweek project will experiment with solutions to this problem.

Concepts to be investigated include

  • Providing reference disk images for package-specific tests for each OS (SLE, Tumbleweed, Leap)
  • Injecting test code into openQA without needing it to be submitted via github. This might include openQA tests being stored as part of the OBS package.
  • Loading package-specific tests in openQA by feeding openQA variables over its REST API
  • Booting these reference images to either a console or X11 as required by the test
  • Testing and providing the results in a meaningful way to the Developer

I will try to find solutions to the above which will work in the following contexts

  • a Developer working 'packageless' with just a git repo and a local compiler (unlikely, but still want to think about it)
  • a Developer working on a package in their OBS Home/Devel project
  • Release Management/Devel Project reviewers of an OBS submit request wanting to see the results of Package Testing BEFORE deciding whether or not the package can be checked-in or forwarded to staging

Join this project

Looking for hackers with the skills:

perl openqa obs

This project is part of:

Hack Week 15

Activity

  • over 6 years ago: tjyrinki_suse liked this project.
  • over 6 years ago: cdywan liked this project.
  • almost 9 years ago: tbechtold liked this project.
  • almost 9 years ago: pgeorgiadis liked this project.
  • almost 9 years ago: szarate liked this project.
  • almost 9 years ago: bchou liked this project.
  • almost 9 years ago: okurz liked this project.
  • almost 9 years ago: pluskalm liked this project.
  • almost 9 years ago: osukup liked this project.
  • almost 9 years ago: diegoakechi liked this project.
  • almost 9 years ago: Knurpht liked this project.
  • almost 9 years ago: aaronluna75 liked this project.
  • almost 9 years ago: RBrownSUSE added keyword "openqa" to this project.
  • almost 9 years ago: RBrownSUSE added keyword "obs" to this project.
  • almost 9 years ago: RBrownSUSE added keyword "perl" to this project.
  • almost 9 years ago: RBrownSUSE liked this project.
  • almost 9 years ago: RBrownSUSE started this project.
  • almost 9 years ago: RBrownSUSE originated this project.


    • Comments

    • RBrownSUSE
      almost 9 years ago by RBrownSUSE | Reply

      Part 2 - Autogenerate X11 tests from Desktop files in packages - including booting the image for the first time, running the app for the first time, and autoneedling for the first time

    • tbechtold
      almost 9 years ago by tbechtold | Reply

      Maybe interessting is the system Debian/Ubuntu uses called autopkgtest. See also https://ci.debian.net/

      • pgeorgiadis
        almost 9 years ago by pgeorgiadis | Reply

        I watched the relevant talk at FOSDEM and it seems really great the fact that they are running all the upstream testsuites plus the fact that they trigger these testsuites against the package's reverse dependencies... (!) But autopkgtest it's tighten only to Debian, which means we can't just take it and use it as it is. We have to come up with our own equivalent system. But the most important part here is that the developers/maintainer has to take care about these upstream tests, so IMHO there has to be an agreement that the src rpm should include the tests into them, and build service has to have the resources + the knowledge on how to run them; then either reject or forward the update up to openQA.

    Similar Projects

    Create a page with all devel:languages:perl packages and their versions by tinita

    Description

    Perl projects now live in git: https://src.opensuse.org/perl

    It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.

    I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta

    But I never had the time to automate this.

    I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).

    Goals

    • Have a script that updates a central repository (e.g. https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run)
    • Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)

    Resources

    MCP Perl SDK by kraih

    Description

    We've been using the MCP Perl SDK to connect openQA with AI. And while the basics are working pretty well, the SDK is not fully spec compliant yet. So let's change that!

    Goals

    • Support for Resources
    • All response types (Audio, Resource Links, Embedded Resources...)
    • Tool/Prompt/Resource update notifications
    • Dynamic Tool/Prompt/Resource lists
    • New authentication mechanisms

    Resources

    openQA log viewer by mpagot

    Description

    *** Warning: Are You at Risk for VOMIT? ***

    Do you find yourself staring at a screen, your eyes glossing over as thousands of lines of text scroll by? Do you feel a wave of text-based nausea when someone asks you to "just check the logs"?

    You may be suffering from VOMIT (Verbose Output Mental Irritation Toxicity).

    This dangerous, work-induced ailment is triggered by exposure to an overwhelming quantity of log data, especially from parallel systems. The human brain, not designed to mentally process 12 simultaneous autoinst-log.txt files, enters a state of toxic shock. It rejects the "Verbose Output," making it impossible to find the one critical error line buried in a 50,000-line sea of "INFO: doing a thing."

    Before you're forced to rm -rf /var/log in a fit of desperation, we present the digital antacid.

    No panic: we have The openQA Log Visualizer

    This is the UI antidote for handling toxic log environments. It bravely dives into the chaotic, multi-machine mess of your openQA test runs, finds all the related, verbose logs, and force-feeds them into a parser.

    image

    Goals

    Work on the existing POC openqa-log-visualizer about few specific tasks:

    • add support for more type of logs
    • extend the configuration file syntax beyond the actual one
    • work on log parsing performance

    Find some beta-tester and collect feedback and ideas about features

    If time allow for it evaluate other UI frameworks and solutions (something more simple to distribute and run, maybe more low level to gain in performance).

    Resources

    openqa-log-visualizer

    MCP Perl SDK by kraih

    Description

    We've been using the MCP Perl SDK to connect openQA with AI. And while the basics are working pretty well, the SDK is not fully spec compliant yet. So let's change that!

    Goals

    • Support for Resources
    • All response types (Audio, Resource Links, Embedded Resources...)
    • Tool/Prompt/Resource update notifications
    • Dynamic Tool/Prompt/Resource lists
    • New authentication mechanisms

    Resources

    openQA tests needles elaboration using AI image recognition by mdati

    Description

    In the openQA test framework, to identify the status of a target SUT image, a screenshots of GUI or CLI-terminal images, the needles framework scans the many pictures in its repository, having associated a given set of tags (strings), selecting specific smaller parts of each available image. For the needles management actually we need to keep stored many screenshots, variants of GUI and CLI-terminal images, eachone accompanied by a dedicated set of data references (json).

    A smarter framework, using image recognition based on AI or other image elaborations tools, nowadays widely available, could improve the matching process and hopefully reduce time and errors, during the images verification and detection process.

    Goals

    Main scope of this idea is to match a non-text status of a running openQA test, an image of a shell console or application-GUI screenshot, using less time and resources and with less errors in data preparation and use, than the actual openQA needles framework; that is:

    • having a given SUT (system under test) GUI or CLI-terminal screenshot, with a local distribution of pixels or text commands related to a running test status,
    • we want to identify a desired target, e.g. a screen image status or data/commands context,
      • based on AI/ML-pretrained archives containing object or other proper elaboration tools,
      • possibly able to identify also object not present in the archive, i.e. by means of AI/ML mechanisms.
    • the matching result should be then adapted to continue working in the openQA test, likewise and in place of the same result that would have been produced by the original openQA needles framework.
    • We expect an improvement of the matching-time(less time), reliability of the expected result(less error) and simplification of archive maintenance in adding/removing objects(smaller DB and less actions).

    Hackweek step

    POC:

    • study the available tools
    • prepare a plan for the process to build
    • write and build a draft application
    • prepare the data archive from a subset of needles
    • initialize/pre-train the base archive
    • select a screenshot from the subset, removing/changing some part
    • run the POC application
    • expect the image type is identified in a good %.

    Resources

    first step of this project is quite identification of useful resources for the scope; some possibilities are:

    • SUSE AI and other ML tools (i.e. Tensorflow)
    • Tools able to manage images
    • RPA test tools (like i.e. Robot framework)
    • other.

    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    Pending

    Debian 13

    The new version of the beloved Debian GNU/Linux OS

    Seems to be a Debian 12 derivative, so adding it could be quite easy.

    • [ ] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • W] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    • [ ] Package management (install, remove, update...)
    • [ ] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). Probably not for Debian as IIRC we don't support patches yet.
    • [ ] Applying any basic salt state (including a formula)
    • [ ] Salt remote commands
    • [ ] Bonus point: Java part for product identification, and monitoring enablement
    • [ ] Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    • [ ] Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)

    Switch software-o-o to parse repomd data by hennevogel

    Run non-stop in escape road, avoid dangerous traps and test your speed to win spectacularly.

    Improvements to osc (especially with regards to the Git workflow) by mcepl

    Description

    There is plenty of hacking on osc, where we could spent some fun time. I would like to see a solution for https://github.com/openSUSE/osc/issues/2006 (which is sufficiently non-serious, that it could be part of HackWeek project).