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
• Only in the case of updating the 2.10 branch:
  • add a commit to modify the rack version in line %define rack_version ... of the dist/obs-bundled-gems.spec file.
• Re-trigger the CI run on the depfu PR and get the PR merged once finished
• Once the depfu PR is merged, check everything is running in build-test.opensuse.org before deploying to build.opensuse.org

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.