repo_checker devel package comments from multiple target projects

A while back the repo_checker gained the ability to post comments on packages within devel projects for which problems were detected in the target project. Since openSUSE:Factory has a fair number of existing problems, many of which are long-standing, it seemed the maintainers needed to be notified of problems rather than users reporting them in the opensuse-factory mailing list or similar. One limitation of the original implementation was that only one comment could exist per devel package. This workflow is standard among the ReviewBots which only post one comment per entity, but it would be preferred to also post reports for openSUSE:Leap:15.0 since the issues may be different.

A bot_name_suffix was introduced to allow for differentiation between the comments based on the target project for which they represent. With this new ability devel package comments were enabled for Leap 15.0 in addition to Factory. An example of two comments on the same package, science/avogadro, can be seen below.


The difference being that i586 is built in Factory, but not Leap.

Another example, from devel:tools:scm/git, demonstrates the importance of posting comments from both target projects since the issue only exists in Leap.


In addition to supporting multiple target projects, the pull request also introduced a configuration option to post comments directly on the packages within the target project. This feature is now used for SLE development which also improves the Leap workflow since many packages come from SLE and the additional check improves the quality of those submissions.

announcer packaging and deployment for Leap 15.0

Leap 42.3 used the announcer to send email notifications of new builds during it pre-release cycle starting with beta. In preparation for using the announcer for Leap 15.0 the various configuration and service bits that were not yet polished and placed in git were merged. After which the package was simply updated and the announcer enabled for Leap 15.0. This is part of a ongoing effort to migrate all services to those provided by the package in order to simplify and ease maintenance.

CI tweaks and osc crash caught

Since requests are now automatically submitted to Leap 15.0 from Factory the openSUSE-release-tools package was submitted which broke the automatic deployment. Before a request is created to submit the package to Factory it checks to ensure there are no existing requests to avoid spamming, but the osc request list command does not differentiate between requests targeting the package or being sourced from it. As such the Leap requests were detected as existing requests. The problem was resolved by replacing the osc command with a custom API call.

Since the CI is ensured to run at least once every 24 hours, after recent tweaks, changes to upstream dependencies (like OBS and osc) that break the release tools are caught quickly. One such occurance was caught that caused osc to crash on init. This confirmed the setup works well and allows for such issues to be caught before deployed in production.

devel project code standardized

Over the last year, the various implementations for retrieving devel project and falling back when not available have been extracted and refactored into common ones. The final request to merge the common implementations remaining into one function (and fix some bugs) was merged. With that refactoring completed the check_source bot could use the fallback code to handle add_role requests to Leap properly. Nothing too exciting, but helpful towards maintaining the code going forward as previously the same problem had to be fixed in each implementation.

post-accept staging todo list

One of the cumbersome bits to the workflow is communicating/remembering manual steps that need to be taken after a staging is accepted. In lieu of the tools handling everything automatically a todo field was added to allow staging masters to record information to be displayed after a staging is accepted. This builds atop the staging specific config feature added and is thus rather simple to implement.

status check

In preparation for providing public status information a tool for determining if the various bots are running properly was created. The intent is to integrate it into a public status site and/or provide alerts to staging masters.


The staging dashboard was improved by krauselukas to include ready requests (adi requests ready to be accepted) and provide links to see all the requests in the various states. This is not only helpful for staging masters to get a quick overview, but helpful to clarify the process to contributors.

last year

During this time last year, an issue reference diffing tool was created to aid in ensuring all fixes from SLE made their way into Factory by comparing the issues referenced in package change logs. The leaper bot was also extended to support SLE and further merged the workflows to allow for investment into the same toolset.

In an effort to improve the staging osc plugin responsiveness the underlying devel project query was reworked to avoid an expensive query that using timed out after 5-10 minutes. The result was a significant speed up.