build.o.o Projects

Of course we make use of the OBS reference server https://build.opensuse.org to ship OBS binaries to our users. Eat your own 🐕 💩 ❗ 😄

For this we have our own top level project OBS:Server and some projects below it and of course (RPM) packages, (KIWI) appliances and (Docker) container images.

Unstable

OBS:Server:Unstable contains OBS binary packages of our master branch and all dependencies needed to build/run those. Packages from O:S:U we deploy in production:

App:

• obs-api 
• obs-api-deps
• obs-bundled-gems
• ruby3.1-rubygem-rack
• perl-GD (used in Webui::Projects::RebuildTimesController.call_diststats)
• sphinx (used by obs-sphinx.service)
• memcached
• telegraf

Ruby:

• ruby3.1
• ruby-common
• ruby3.1-rubygem-gem2rpm
• libruby3_1-3_1

Application Server

• rubygem-passenger
• ruby3.1-rubygem-passenger
• apache2-mod_xforward
• rubygem-passenger-apache2

$VERSION

OBS:Server:$VERSION contains binary packages of our release branch (e.g. 2.10) and all dependencies needed to build/run those. This is the repository our users have enabled on their operating system.

$VERSION:Staging

As you can imagine we don't want our users to immediately get all changes we do to our packages delivered to their systems. We want this to be timed and tested releases. That is why packaging for released versions happens in a sub-project called OBS:Server:$VERSION:Staging. Any package you want to add or update should be packaged there.

The full release process is documented in our minor (updates of 2.10.<minor-version>) and major (updates of 2.<major-version>) release guides.

NOTE: Changes to the OBS project configuration (prjconf or repositories etc.) should be done in both OBS:Server:$VERSION:Staging and OBS:Server:$VERSION so users can base their branches in OBS on the released project.

Updating rake or rack

Whenever Depfu is sending a PR about updating rake or rack the CI workflow passenger_tests will fail because we are consuming those two gems from the system and not our bundle. This is because the application server we use (phusion passenger) via packages requires rake / rack too. So we can't have a rake or rack version in our bundle that does not come from the system. Exactly this is what the CI workflow passenger_tests tests.

Rack update

If there is a rack update you will have to

• Branch the rubygem-rack-2.2 package
• Update the package to the version that depfu wants to update to
• Submit Request the package and get it merged to devel:languages:ruby:extensions.
• Point OBS:Server:Unstable to the new version with osc setlinkrev.
• Wait until the package has finished building in OBS:Server:Unstable
• Wait until the dependent CI containers in (OBS:Server:Unstable:Containers) have finished building
• Re-trigger the CI run on the depfu PR and get the PR merged once finished

Please note: It might be needed to re-trigger some other CI pipeline so they pick up the new CI containers images.

Rake update

rake updates, on the other hand, rarely happen and you usually don't have to do them. If they only bring functional updates we usually omit them, if they bring security update we rely on the fixes being backported by the openSUSE ruby package maintainer in devel:languages:ruby. If there is a rake update you will have to

• In case of a security problem, make sure the openSUSE ruby maintainer is aware
• In case of "only" functional update, close the PR.

Base64

We apply the approach we use with Rake with the base64 gem.