We need statistical analysis and key performance indicators to describe the lifetime of maintenance and release requests in IBS, for example:

  • How long does an update take starting from the time the first maintenance request is created and stopping at the time the update is released to customers?

  • How long does it take for a maintenance request to pass all required reviews?

  • How often do reviews succeed or fail, respectively?

  • How long does it take to create a release request after a maintenance incident has been created?

  • How do these values look, on average, across different code streams?

  • What is the absolute number of requests opened (or closed) in a given time period (per code stream)?

This information is particularly important for the Emergency Updater Team, which defines success and failure partly through the time it takes to release an update to customers.

Almost all of that information is available in IBS (OBS) in one way or another, but it is hard to retrieve the data in a format that's easy to analyze.

The aim of this Hackweek project is to remedy that issue by writing one or several tools that query IBS/OBS and generate a relational database in Sqlite3 or MySQL that contains all necessary information for further analysis with standard tools, like R, scripting languages, or spread sheets in a simple format (schema). The focus of this effort would be to support build.suse.de (IBS), but we assume that supporting build.opensuse.org (OBS) as well will be feasible, if not even trivial.

There is a relevant FATE issue at https://fate.suse.com/319971 that we'll need to take into consideration.

This project was initially discussed during the MaintSec 2016 workshop, and most of the original notes are still available at https://etherpad.nue.suse.com/p/TeamSaturn. Since then, some research and experimentation has taken place under the umbrella of https://redmine.nue.suse.com/issues/5785 and https://redmine.nue.suse.com/issues/4276.

Looking for hackers with the skills:

obs buildservice

This project is part of:

Hack Week 15

Activity

  • almost 8 years ago: vitezslav_cizek liked this project.
  • almost 8 years ago: tgoettlicher joined this project.
  • almost 8 years ago: tgoettlicher liked this project.
  • almost 8 years ago: osukup joined this project.
  • almost 8 years ago: hennevogel liked this project.
  • almost 8 years ago: hurhaj liked this project.
  • almost 8 years ago: osukup liked this project.
  • almost 8 years ago: psimons added keyword "obs" to this project.
  • almost 8 years ago: psimons added keyword "buildservice" to this project.
  • almost 8 years ago: pluskalm liked this project.
  • almost 8 years ago: psimons started this project.
  • almost 8 years ago: psimons originated this project.

  • Comments

    • hennevogel
      almost 8 years ago by hennevogel | Reply

      Nice project! You are aware that the BS-Team has implemented the data gathering part of this feature? It's not yet in production but it's on the way -> Pull Request #2507

      BTW if you want to do this inside the OBS and not with an external tool I would be interested in introducing you to OBS development and helping you during hackweek. Let me know :-)

    • leonardocf
      almost 8 years ago by leonardocf | Reply

      You might find https://gitlab.suse.de/maintenance/pymaint useful

    Similar Projects

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

    Currently software.opensuse.org search is using the OBS binary search for everything, even for packages inside the openSUSE distributions. Let's switch this to use repomd data from download.opensuse.org


    Explore the integration between OBS and GitHub by pdostal

    Project Description

    The goals:

    1) When GitHub pull request is created or modified the OBS project will be forked and the build results reported back to GitHub. 2) When new version of the GitHub project will be published the OBS will redownload the source and rebuild the project.

    Goal for this Hackweek

    Do as much as possible, blog about it and maybe use it another existing project.

    Resources


    Bootstrap openSUSE on LoongArch by glaubitz

    Description

    LoongArch is a new architecture from China which has its roots in the MIPS architecture. It has been created by Loongson and is already supported by Debian Ports, Gentoo and Loongnix.

    Upstream support for LoongArch is already quite complete which includes LLVM, Rust, Golang, GRUB, QEMU, LibreOffice and many more. In Debian Ports, where the port is called "loong64", more than 95% of the whole Debian archive have been successfully built for LoongArch.

    QEMU support is rather complete and stable such that packages can be built in emulated environments. Hardware can also be requested by Loongson on request for free. Access to real hardware is also provided through the GCC Compile Farm.

    Goals

    The initial goal should be to add LoongArch to OBS and build a minimal set of packages.

    Resources

    Results

    Acknowledgements

    • Thanks to Adrian Schröter and Rüdiger Oertl for the help with setting up the FTP space and OBS project
    • Thanks to Dirk Müller for the input on how to get started with a new port
    • Thanks to Richard Biener for quickly accepting my submit requests to add loongarch64 support to the toolchain


    Fix RSpec tests in order to replace the ruby-ldap rubygem in OBS by enavarro_suse

    Description

    "LDAP mode is not official supported by OBS!". See: config/options.yml.example#L100-L102

    However, there is an RSpec file which tests LDAP mode in OBS. These tests use the ruby-ldap rubygem, mocking the results returned by a LDAP server.

    The ruby-ldap rubygem seems no longer maintaned, and also prevents from updating to a more recent Ruby version. A good alternative is to replace it with the net-ldap rubygem.

    Before replacing the ruby-ldap rubygem, we should modify the tests so the don't mock the responses of a LDAP server. Instead, we should modify the tests and run them against a real LDAP server.

    Goals

    Goals of this project:

    • Modify the RSpec tests and run them against a real LDAP server
    • Replace the net-ldap rubygem with the ruby-ldap rubygem

    Achieving the above mentioned goals will:

    • Permit upgrading OBS from Ruby 3.1 to Ruby 3.2
    • Make a step towards officially supporting LDAP in OBS.

    Resources


    Learn obs/ibs sync tool by xlai

    Description

    Once images/repo are built from IBS/OBS, there is a tool to sync the image from IBS/OBS to openqa asset directory and trigger openqa jobs accordingly.

    Goals

    Check how the tool is implemented, and be capable to add/modify our needed images/repo in future by ourselves.

    Resources

    • https://github.com/os-autoinst/openqa-trigger-from-obs
    • https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin/-/tree/master?ref_type=heads