Archive:Build Service Junior Jobs

Jump to: navigation, search
Icon-obsolete.png This article about the Open Build Service is obsolete!
You can find up to date information on https://github.com/openSUSE/open-build-service/contribute

This page is about smaller open development tasks for the Open Build Service. These tasks are a good start to dive into OBS development and Ruby on Rails development.

We have collected the following tasks:

Help us to raise our quality

The OBS comes with test suites to validate our code. The test suite is running before we deploy or package releases. So a good test suite will lead to a good product. Unfortunately there are plenty areas which are not covered by the testsuite yet, but luckily it is easy to write more tests. Check here to learn how to run and develop tests.

Show more status information in web user interface

The backend already knows a lot of data like history and status information which are not visible in the web client. These information can get requested in via the API already, but are not accessible via our clients yet.

This means also that you do not need an own full Open Build Service for development. You just need to run a local web client on your system, which uses our official Open Build Service instance behind api.opensuse.org. You can read here how to run it on your system.

Manage project sign key in web interface

Add a view for the signkey in projects. Details can be found in the feature request.

Improve Package Page

The package page currently shows all current sources, but nothing else. However the backend system knows a lot more about it:

  • Open submission requests: Submission requests are requests to merge a change into the package. This can be seen with "osc sr list" command already. However a nice way to see open submission requests for the package, an easy way to see the changes and to approve or decline would be nice.
  • Merged source link: The web client always shows "unexpanded" sources. This means that packages with source links show the "_link" file plus patches. The backend offers to expand the source link, this means to show the sources with applied patches. It would be nice to have switch to show the merged sources in this view also. Almost done by Jan Loeser.
  • Commit log: A log of source commits could be shown. Maybe also with displaying the diff. And maybe even a function to revert to this state :)

Dependency helper

  • You lack a package dependency to be able to build your package ? A wizard could help here a lot, it should search for this dependency and than offer:
    • Add further repo to build against (when package exists for your platform there)
    • source link the package (if it got not yet built for your platform yet)

Publisher improvements

The Open Build Service publisher is a relative simple perl script, so it is an easy way to dig into the backend source.

nu file support in publisher

zypper supports the nu files since openSUSE 11.1. These are repo descriptions which allows to add further repos. This means, when a user adds the KDE:KDE4.3 repo and the packager decides later that he wants to build this against KDE:Qt46, zypper will automatically use this repo as well.

Background information about this format can be found here and in this blog from Duncan.

Senior Jobs

This was all too easy and boring for you ? We have also tasks which need extensions in the backend, in the api front-end and web client. This means you need a local instance of the Open Build Service for developing.

Improve Monitor Page

  • Add Scheduler Statistics: The scheduler collects already all kind of statistics for performance tuning. The file $BUILD_SERVICE_ROOT/info/schedulerinfo.$arch contains informations about used resources of the scheduler, events to process and also which are the projects which take most resources. This should become requestable via source and repository server, in the api and become displayed in the web client.
  • Add repo setup status: The scheduler does find out about dependency loops between packages and repositories. This information is currently not stored anywhere but would be very helpful for developers. The job is to stored this information on disk, make it requestable in src, rep server and api. And last but not least display it in the Web interface platform page.