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
#includesfiles (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:
Reproducible builds in Fedora (security reasons are discussed more)
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 --helposc jobhistory --help
Looking for hackers with the skills:
This project is part of:
Hack Week 10 Hack Week 11
Activity
Comments
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
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
Learn about OSB and contribute to `kustomize` and `k9s` packages to add ARM arch by dpock
Description
There are already k9s and kustomize packages that exist for openSUSE today. These could be used as the source for these binaries in our rancher projects. By using them we would benefit from CVE fixes included in our distribution of the packages not in cluded upstream. However they are not providing arm package builds which are required.
Goals
- [ ] Update the kustomize package in OBS to use the newest version and send change request
Resources
- k9s: https://build.opensuse.org/package/show/openSUSE:Factory/k9s
- kustomize: https://build.opensuse.org/package/show/openSUSE:Factory/kustomize
- Learning Docs: https://confluence.suse.com/display/packaging/Training%2C+Talks+and+Videos
Research openqa-trigger-from-obs and openqa-trigger-from-ibs-plugin by qwang
Description
openqa-trigger-from-obs project is a framework that OSD is using it to automatically sync the defined images and repositories from OBS/IBS to its assets for testing. This framework very likely will be used for the synchronize to each location's openqa include openqa.qa2.suse.asia Beijing local procy scc scc-proxy.suse.asia(although it's not a MUST to our testing) it's now rewriting requests to openqa.qa2.suse.asia instead of openqa.suse.de, the assets/repo should be consistent the format Beijing local openQA is maintaining an own script but still need many manually activities when new build comes, and not consistent to OSD, that will request many test code change due to CC network change
Goals
Research this framework in case it will be re-used for Beijing local openQA, and will need to be setup and maintained by ourselves
Resources
https://github.com/os-autoinst/openqa-trigger-from-obs/tree/master https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin
beijing :rainbow machine
New features in openqa-trigger-from-obs for openQA by jlausuch
Description
Implement new features in openqa-trigger-from-obs to make xml more flexible.
Goals
One of the features to be implemented: - Possibility to define "VERSION" and "ARCH" variables per flavor instead of global.
Resources
https://github.com/os-autoinst/openqa-trigger-from-obs
Create object oriented API for perl's YAML::XS module, with YAML 1.2 Support 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
- Experimental release waiting for user feedback: https://github.com/perlpunk/yaml-libyaml-pm/releases
- Diff