A social network for Bugs and test cases!

Connecting bugs with test cases, products and each other. Making them depressed and easily mislead. Allowing us to interfere with their elections and sell them solutions to problems they didn't even know they had.

Bug-Graph repo

Also I plan to integrate this with OpenQA, so far I have basic library for connecting to the OpenQA web API.

OpenQA Rust lib

blog post

Image of the result matrix feature

Looking for hackers with the skills:

openqa rust

This project is part of:

Hack Week 17

Activity

  • over 7 years ago: rpalethorpe started this project.
  • over 7 years ago: rpalethorpe added keyword "openqa" to this project.
  • over 7 years ago: rpalethorpe added keyword "rust" to this project.
  • over 7 years ago: rpalethorpe added keyword "openqa" to this project.
  • over 7 years ago: rpalethorpe added keyword "rust" to this project.
  • over 7 years ago: rpalethorpe originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    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


    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 "graphical" image of the console or GUI 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 POC:

    Main steps

    • Phase 1 - Plan
      • study the available tools
      • prepare a plan for the process to build
    • Phase 2 - Implement
      • write and build a draft application
    • Phase 3 - Data
      • 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
    • Phase 4 - Test
      • 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.

    Project references


    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


    Bring up Agama based tests for openSUSE Tumbleweed by szarate

    Description

    Agama has been around for some time already, and we have some tests for it on Tumbleweed however they are only on the development job group and are too few to be helpful in assessing the quality of a build

    This project aims at enabling and creating new testsuites for the agama flavor, using the already existsing DVD and NET flavors as starting points

    Goals

    • Introduce tests based on the Agama flavor in the main Tumbleweed job group
    • Create Tumbleweed yaml schedules for agama installer and its own jsonette profile (The one being used now are reused from leap)
    • Fan out tests that have long runtimes (i.e tackle this ticket)
    • Reduce redundancy in tests

    Resources


    Looking at Rust if it could be an interesting programming language by jsmeix

    Get some basic understanding of Rust security related features from a general point of view.

    This Hack Week project is not to learn Rust to become a Rust programmer. This might happen later but it is not the goal of this Hack Week project.

    The goal of this Hack Week project is to evaluate if Rust could be an interesting programming language.

    An interesting programming language must make it easier to write code that is correct and stays correct when over time others maintain and enhance it than the opposite.


    Build a terminal user-interface (TUI) for Agama by IGonzalezSosa

    Description

    Officially, Agama offers two different user interfaces. On the one hand, we have the web-based interface, which is the one you see when you run the installation media. On the other hand, we have a command-line interface. In both cases, you can use them using a remote system, either using a browser or the agama CLI.

    We would expect most of the cases to be covered by this approach. However, if you cannot use the web-based interface and, for some reason, you cannot access the system through the network, your only option is to use the CLI. This interface offers a mechanism to modify Agama's configuration using an editor (vim, by default), but perhaps you might want to have a more user-friendly way.

    Goals

    The main goal of this project is to built a minimal terminal user-interface for Agama. This interface will allow the user to install the system providing just a few settings (selecting a product, a storage device and a user password). Then it should report the installation progress.

    Resources

    • https://agama-project.github.io/
    • https://ratatui.rs/

    Conclusions

    We have summarized our conclusions in a pull request. It includes screenshots ;-) We did not implement all the features we wanted, but we learn a lot during the process. We know that, if needed, we could write a TUI for Agama and we have an idea about how to build it. Good enough.


    Learn how to use the Relm4 Rust GUI crate by xiaoguang_wang

    Relm4 is based on gtk4-rs and compatible with libadwaita. The gtk4-rs crate provides all the tools necessary to develop applications. Building on this foundation, Relm4 makes developing more idiomatic, simpler, and faster.

    https://github.com/Relm4/Relm4


    Arcticwolf - A rust based user space NFS server by vcheng

    Description

    Rust has similar performance to C. Also, have a better async IO module and high integration with io_uring. This project aims to develop a user-space NFS server based on Rust.

    Goals

    • Get an understanding of how cargo works
    • Get an understanding of how XDR was generated with xdrgen
    • Create the RUST-based NFS server that supports basic operations like mount/readdir/read/write

    Result (2025 Hackweek)

    • In progress PR: https://github.com/Vicente-Cheng/arcticwolf/pull/1

    Resources

    https://github.com/Vicente-Cheng/arcticwolf


    Mail client with mailing list workflow support in Rust by acervesato

    Description

    To create a mail user interface using Rust programming language, supporting mailing list patches workflow. I know, aerc is already there, but I would like to create something simpler, without integrated protocols. Just a plain user interface that is using some crates to read and create emails which are fetched and sent via external tools.

    I already know Rust, but not the async support, which is needed in this case in order to handle events inside the mail folder and to send notifications.

    Goals

    • simple user interface in the style of aerc, with some vim keybindings for motions and search
    • automatic run of external tools (like mbsync) for checking emails
    • automatic run commands for notifications
    • apply patch set from ML
    • tree-sitter support with styles

    Resources

    • ratatui: user interface (https://ratatui.rs/)
    • notify: folder watcher (https://docs.rs/notify/latest/notify/)
    • mail-parser: parser for emails (https://crates.io/crates/mail-parser)
    • mail-builder: create emails in proper format (https://docs.rs/mail-builder/latest/mail_builder/)
    • gitpatch: ML support (https://crates.io/crates/gitpatch)
    • tree-sitter-rust: support for mail format (https://crates.io/crates/tree-sitter)