Reduce the number of builds in the openSUSE Build Service
a project by dmuhamedagic
Updated over 5 years ago. 3 hacker ♥️.

In case any of the source files changed, openSUSE Build Service rebuilds the dependent packages regardless of whether that particular modification affects the dependency. This makes our resources footprint bigger (and the electrical power bills higher). It also affects users, because every new package build causes the package manager to include that package in the next update thus consuming network bandwidth and resources of users' computers.

Current OBS controls for package rebuild triggers

It is possible to control dependent packages build triggers on a per repository basis (see OBS build scheduling strategies). You will find an explanation on that page that any setting other than the default, which is "always rebuild", is not safe and should not be used if the packages are to be distributed. Apparently, the concern is more of a "this repository is official/testing" kind.

Which modifications justify rebuilding

First, we need to define the modifications which justify rebuilding the dependencies. This is a list which should be amended by the more knowledgeable on software builds:

  • new library versions or binary API changes (the latter should always cause the former?)

  • changes in #includes files (in case of library development packages); it is preferable to verify if the dependencies can build with these modifications sooner rather than later

Possible improvements

Extend the checkin command

I suppose that this is a hard problem to solve automatically, so it is good to start small with some infrastructure to allow managing the dependencies rebuild process. We could add the "don't rebuild/must rebuild dependencies" option to the checkin command.

Make builds reproducible

There are ongoing efforts to get reproducible builds, that is if the source has not changed, then the built package should be exactly equal to the previous build too.

According to osc triggerreason on several packages in the openSUSE Build Service reference instance, quite a few rebuilds were due to md5 sum not matching. If more builds were reproducible that would obviously reduce the total number of builds. More, a reproducible build would (almost) completely remove transitive builds (see the build project attribute).

See the following pages for more information:

Questions

  • Is there a facility in OBS similar to the Debian's dh_buildinfo? Would that be useful in OBS? Is there a way to keep that information within the existing infrastructure?

  • How are md5 sums produced?

Resources

  • osc triggerreason --help

  • osc jobhistory --help

Join this project

Looking for hackers with the skills:

obs perl buildservice parsing

This project is part of:

Hack Week 10 Hack Week 11

Activity

  • almost 9 years ago: aspiers liked this project.
  • about 10 years ago: im_unbob liked this project.
  • about 10 years ago: dmuhamedagic added keyword "parsing" to this project.
  • about 10 years ago: dmuhamedagic added keyword "buildservice" to this project.
  • about 10 years ago: dmuhamedagic added keyword "perl" to this project.
  • about 10 years ago: dmuhamedagic added keyword "obs" to this project.
  • about 10 years ago: dmuhamedagic added keyword "obs" to this project.
  • about 10 years ago: dmuhamedagic started this project.
  • about 11 years ago: keichwa liked this project.
  • about 11 years ago: dmuhamedagic added keyword "obs" to this project.
  • about 11 years ago: dmuhamedagic originated this project.


    • Comments

    • aspiers
      almost 9 years ago by aspiers | Reply

      There's also now a nice distro-agnostic website.

    Similar Projects

    obs-service-vendor_node_modules by cdimonaco

    Description

    When building a javascript package for obs, one option is to use https://github.com/openSUSE/obs-service-node_modules as source service to get the project npm dependencies available for package bulding.

    obs-service-vendornodemodules aims to be a source service that vendors npm dependencies, installing them with npm install (optionally only production ones) and then creating a tar package of the installed dependencies.

    The tar will be used as source in the package building definitions.

    Goals

    • Create an obs service package that vendors the npm dependencies as tar archive.
    • Maybe add some macros to unpack the vendor package in the specfiles

    Resources

    Implement a full OBS api client in Rust by nbelouin

    Description

    I recently started to work on tooling for OBS using rust, to do so I started a Rust create to interact with OBS API, I only implemented a few routes/resources for what I needed. What about making it a full fledged OBS client library.

    Goals

    • Implement more routes/resources
    • Implement a test suite against the actual OBS implementation
    • Bonus: Create an osc like cli in Rust using the library

    Resources

    • https://github.com/suse-edge/obs-tools/tree/main/obs-client
    • https://api.opensuse.org/apidocs/

    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

    Automation of ABI compatibility checks by ateixeira

    Description

    ABI compatibility checks could be further automated by using the OBS API to download built RPMs and using existing tools to analyze ABI compatibility between the libraries contained in those packages. This project aims to explore these possibilities and figure out a way to make ABI checks as painless and fast as possible for package maintainers.

    Resources

    https://github.com/openSUSE/abi-compliance-checker

    https://github.com/lvc/abi-compliance-checker

    https://sourceware.org/libabigail/

    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

    Create object oriented API for perl's YAML::XS module by tinita

    Description

    YAML::XS is a binding to libyaml and already quite old, but the most popular YAML module for perl. There are two main issues:

    • It uses global package variables to influence behaviour.
    • It didn't implement the loading of types like numbers and booleans according to the YAML spec (neither 1.1 nor 1.2).

    Goals

    Create a new interface which works object oriented. Currently YAML::XS exports a list of functions.

    • The new API will allow to create a YAML::XS object containing configuration influencing the behaviour of loading and dumping.
      • It keeps the libyaml parser and emitter structs in memory, so repeated calls can save the creation of those structs
    • It will by default implement the YAML 1.2 Core Schema, so it is compatible to other YAML processors in perl and in other languages
    • If I have time, I would like to add the merge << key feature as an option. We could then use it in openQA as a replacement for YAML::PP to be faster.

    I already created a proof of concept with a minimal functionality some weeks before this HackWeek.

    Resources

    • Work is currently happening on the oop branch