Build Service/Junior Projects

From openSUSE

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

We have collected the following tasks:

Show more status information in web client

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

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

Create New Default Web Theme

Thomas Schmidt is currently implementing the theme handling into the webclient. Another theme is wanted to verify that all needed parts can be themed. We should verify with this that there are no hardcoded URLs to opensuse.org addresses anymore.

We should package this theme as default theme for our obs-server packages.

Improve Platform Page

The platform page of a build service project shows the status of the repository. It looks pretty boring right now.

Informations which could get added there:

• build history: What are the last package builds for this repository and architecture. You can get this information via the https://api.opensuse.org/build/$project/$repository/$arch/_jobhistory api call, the trigger reason is part of it.
• build reason: Show the reason why a package build got triggered. This can get requested via /build/$project/$repository/$arch/$package/_reason api call.
• package build history: Each package has a own history (in addition to the entire repository), when it got built in the past. This is not visible yet.

Improve Package Page

The package page currently shows all current sources, but nothing else. However the backend system know 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 show "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 :)

Improve Project Page

• Project config show/edit mode: The project config is currently not accessible at all via the web interface. Even though you can do powerful stuff with it. We have already a view and edit page for editing source files. It should be easy to allow editing of the project config also. A project config can be accessed with "osc meta prjconf openSUSE:Factory" for example. Max is working on this.

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 plattform there)
  • source link the package (if it got not yet built for your plattform yet)

Publisher improvements

The 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 since openSUSE 11.1 the nu files. 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 informations 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 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.