https://github.com/bmwiedemann/obsbugzilla

update bugzilla entries from OBS submitrequest info
https://github.com/bmwiedemann/obsbugzilla

Last synced: 17 days ago
JSON representation

update bugzilla entries from OBS submitrequest info

• Host: GitHub
• URL: https://github.com/bmwiedemann/obsbugzilla
• Owner: bmwiedemann
• Created: 2013-09-18T13:12:17.000Z (over 11 years ago)
• Default Branch: master
• Last Pushed: 2024-04-18T08:26:41.000Z (8 months ago)
• Last Synced: 2024-04-18T10:22:10.357Z (8 months ago)
• Language: Perl
• Size: 92.8 KB
• Stars: 6
• Watchers: 3
• Forks: 3
• Open Issues: 0
• Metadata Files:
  • Readme: README

Awesome Lists containing this project

README

        
This tool updates bugzilla entries with information

from OBS submit requests that mention bnc#

Why?

Because it helps

* to get notified of progress of your bug

* to find which package got which change to fix the bug

* to find if/when the fix was done and to which codestreams it was already submitted

Normally, Bernhard is running these scripts for everyone (one instance for OBS and another for IBS).

For running this yourself, you need a ~/.bugzillarc with

$username="yourbugzillaaccount";

$password="xxx";

$namespace="openSUSE:";

INSTALL:

  zypper in perl-SOAP-Lite perl-XMLRPC-Lite perl-JSON-XS perl-LWP-Protocol-https perl-MLDBM python-pika osc

To use this tool with bnc's XMLRPC,

you need an account with the corporate flag set

Once configs are in place, configure via crontab -e

0 * * * * cd ~/obsbugzilla && ./sourceobs.pl # fallback if something goes wrong with rabbitmq

*/10 * * * * cd ~/obsbugzilla && ./sink.pl

and run ./sourcerabbit.pl as a permanent source process

How it works:

The script queries OBS for SRs of the last 24 hours, looks into the commit message (but not the .changes file) for bnc# mentions and updates bugzilla using the XML-RPC API.

Implementation details:

The script maintains an issuemention.dbm file about mentions that were already processed in order to avoid duplicates in bugzilla, even when it misbehaves.

Data is collected by code in source/*.pm and relevant entries are written to a pending queue dir by the various sources. E.g. queue/bnc#1234567/sr543210

A sink process picks up entries from the queue when data is sufficiently aggregated (similar in spirit to TCP's Nagle algorithm) to avoid spamming bug-subscribers with emails about single SRs, but also not causing large delays in information flow. When bugzilla is down, enries remain in the queue. Updates for inaccessible bugs (usually about legal issues) have to be discarded.

There are currently 2 sources: rabbitmq via a continuously running `sourcerabbit-wrapper.sh` process and as fallback regular OBS search API queries.

As long as rabbitmq works fine, the fallback runs, but adds nothing to the queue. In case of trouble, the effect will be that updates only occur every 2 hours, 30-40 minutes after the cron-job ran.

There are currently 2 sinks: bugzilla and jira. These update bugzilla.suse.com and jira.suse.com with links to SRs.

maintenance:

Ocassionally, the bugzilla server will misbehave and updating a bug fails. Then use `retrymany` with the failure email message as input (copy+paste works).