Highlights of the OBS frontend development - Sprint 41 & 42

It has been quite a lot of time since our last blog post. :sob: We were so focussed in our Hackweek projects last week that we didn’t find time to write about our last sprints. But now that they are already finished, it is time to keep you up-to-date with the development of OBS! :tada: This is what the OBS frontend team has achieved in the last two sprints (2018-06-18 to 2018-07-06), being the last sprint only one week due to the start of the Hackweek.


Multibuild support

We were not sure if some of our package related views, job history, build reason and build statistics page, supported multibuild. We checked it and found out that some of them were showing the wrong content. As in other pages where the multibuild was not supported, it was needed to store the given package name instead of using the name from the package taken from the database. This two names are normally the same, but in the multibuild case, as the multibuild package doesn’t exist in the database, it is the container package instead. This was done for example in PR#5161 and you can now check the job history, build reason and build statistics for you multibuild packages too! :bowtie:

Bug squad

As you might know, we organize our work with Scrum. Scrum is an agile methodology which basically means we plan our work in sprints (currently two weeks) and after each sprint we come together and review what we accomplished and plan our next sprint. However, as our GitHub issues list is growing faster and faster (currently > 500 issues open :scream:), we decided to introduce a new role in our team which is seperated from our Scrum process and does focus only in fixing bugs :bug:! We wrote down these tasks for this role:

  • Handle support questions on the opensuse-buildservice mailing list
  • Handle support questions on the opensuse-buildservice IRC channel
  • Answer questions that came up on Twitter (@obshq)
  • Go through the list of issues without label and assign topic/priority labels
  • Fix bugs of your choosing (by priority)

Most of the bugs we fixed so far were just small issues but many small fixed issues eventually pile up to something big :smile:. In the sprint 42, which was only one week, we already fixed seven open issues :muscle:. Have you already figured out which one? Find a complete list in the Bug squad Trello card.


Ludwig requested in issue #5084 to have links to the diffs to the new, superseeding requests of a submit Request with more than one superseeding requests. :male_detective: In the pull request #5162 the feature was implemented. :construction_worker_man: Moreover, in pull requests #5166 appearance of the links was fixed and in #5190 the code was improved. :man_student:

several requests message

Bundle gems service

We recently implemented the bundle_gems source service and are still in the process of gathering experience in using it. The objective is to use it soon for our obs-server package and getting rid of packaging rubygems for it. As we recently switched to use containers in our CI (in Travis and CircleCI) which we already build in OBS, it was time to use the bundle gems service there to implement a gem cache inside the container image. This has the advantage that we do not need to download the gems in every CI run (the gems were already cached but it is still an improvement) and it also makes it more similar to our development environment.

The images we use in CI we build in OBS. This is great as we always get a new image when a dependency gets updated. And if you don’t know, there are currently two different ways of building container images in OBS. Using Kiwi or docker native builds. The former is mostly used to build a base image from where other images can then derive. The latter is what you know from your standard docker build workflow. Because we used docker images before the native docker build was fully supported in OBS, we were still using Kiwi. And as it turned out, integrating the bundle gems service into Kiwi image builds was impossible. So we took the opportunity and switched our images to docker native builds. Before we finally could use the service, we also needed to fix two bugs. The OBS project can be found here. All in all was this a really good way to test the new service in a real use case. :+1:

Obs Factory Integration

One of our propose was merging Factory dashboard code base into OBS, after 2 sprints we finally merge it :tada:. Our next step will be add tests for it.

Frontend migration

One of our short term objective is to replace the OBS frontend technology with bootstrap and rework most of the views. The next two topics are about this.

Pattern library

One of our main goals with the rework of the OBS views are to make the views look consistent and easy to maintain. To help to achieve this goal, we decided to introduce a pattern library which is a collection of user interface design elements. So if you want to add for instance a breadcrumb element to one of the views, you go to the OBS pattern library and search for ‘breadcrumbs’. This page then shows you a preview of the element as well as the code which you can just copy and paste. Neat, isn’t it?


When changing the views, most of our tests should be uneffected and still pass. However, we also have feature tests which are high level functional tests for certain workflows. And most likely some of our feature tests will break with the new bootstrap theming. For now, the bootstrap theming is only available for Admin users which is also a problem when it comes to testing because the success of the test depends then on the user. So we changed this for our test suite that we can explicitly run a test with bootstrap enabled or disabled. With this in place, we introduced another CircleCI job which runs our feature tests with bootstrap enabled and all other tests run with bootstrap disabled. We also implemented a switch to disable a test in case it is not possible to make it work for the old and new theming and the possibility to add new tests only for bootstrap. Have a look at this PR if you want to know more.

Continuous integration

Since a while we were already experimenting with containers and CircleCI. This sprint we finally decided to move from Travis CI to CircleCI because of several reasons. Some of these reasons include:

  • Better native container support
  • Uploading of test results possible (screenshots logs)
  • Live debugging with SSH access
  • Faster through better support of running tests in parallel
  • More flexibilty

One of our longtime contributor, Coolo, also started to contribute more and more recently and improved the CI speed significantly. Have a look at PR#5331, PR#5361 and PR#5350.

Test suite migration

We also continued to migration and improve our test suite by increasing the code coverage for the webui request controller and once there we refactored some bits in the request_controller too.


Brighton Ruby

Appart from the hard work, the OBS developers also like to speak about it in conferences. In this case, Ana travelled to Brighton Ruby to give a talk about her work in OBS: Let’s Refactor Some Ruby Code. According to some of the speakers it was a humorous and self-deprecating talk, where Ana shared some Ruby Code she refactored in OBS and what she learnt from it.

Let’s Refactor Some Ruby Code by Ana

Brighton Ruby was a really nice organized conference, with interesting talks, nice people and ice cream! :icecream: Appart from Ana’s talk, it is worthwhile to mention some others as well:

All the talks where recorded. They are not available yet, but you will be able to watch them soon! :wink:

Next Sprint more

That was everything! Remember you can follow the work of the OBS team live in our Trello Board. Do not miss our next blog post! :wink: