better notification and user feedback
- Use something like https://github.com/bmwiedemann/obsbugzilla to interface with bugzilla and report on updates in product bugs -> #27844
- IRC bot with updates about test runs, e.g. if builds are finished -> #27847
- email notification -> #10672
- RSS feeds
- better feedback depending on observer roles
- tags and comments on anything,
further notes and references¶
- some ideas about obs and openqa notifications: https://etherpad.nue.suse.com/p/obs_and_openqa
#2 Updated by oholecek almost 6 years ago
Wrt notifications: during hackweek I created very primitive prototype of fedmsg plugin for openQA. I plan to revive it later (use actual 0mq perl bindings, add support to receive notifications, ...) and also write something similar for OBS.
Fedmsg already provides tools like IRC bot, mailer daemon, archiving, ... for same or similar use case we have - in my hackweek setup I tested openQA->IRC notifications. It's in python, based on 0mq.
#5 Updated by okurz almost 6 years ago
I looked at it and it looks awesome to me. IMHO we might still add some very simple notification as a short term solution and in mid term we should use something as you proposed based on proper infrastructure.
short term suggestions:
- maybe not even built into openQA but by an external tool, e.g. an IRC bot in its own room? This way people can more easily decide for themselves if they want to get notifications or not
- provide a way to register plugins in files within openqa webapi like you did in https://github.com/aaannz/openQA/commit/31e30cc635afff6a1814739fbb03727d2ebb73d1 but do something like scan a directory for files of a certain name convention and load all these. This way we can provide very SUSE specific notification plugins (easy to hack) while keeping upstream openQA clen
#6 Updated by okurz over 5 years ago
about email notification, this could be interesting: http://search.cpan.org/~sharifuln/Mojolicious-Plugin-Mail-1.5/lib/Mojolicious/Plugin/Mail.pm
#7 Updated by okurz over 5 years ago
Further ideas from #10212 that were not covered in the feature so far:
- Add specific labels to each test result as proposed by RBrownSUSE, e.g. for STATUS (broken: flash, passing and correct (false negative): checked, failing and correct: ban)
- Add a persistent label feature to each test scenario, i.e. add edit field on each test run but preserve it over runs
- Use tags for multiple instances of a single tag
- comment carry over:
- failed->passed: emit event and/or hook to inform that an issue got fixed -> potential candidate for resolving/verifying a bug
- failed->failed: be careful not to miss new issues, e.g. when test "degrades"
- extension to check for "improved"/"degraded", e.g. less successful modules executed
- a simple carry over approach could be: as soon as job is finished, i.e. results are entered into the database, IF job is NOT passed, the previous jobs of same scenario are parsed, IF any comments found (including label, bug, etc.) THEN IF bug OR label, copy to current job
#15 Updated by okurz about 4 years ago
With a big chunk of work done in #12092 to show the status of the current bugs on osd we progressed a lot. Considering that there has not been any movement in this ticket for the past 5 months we could be honest to ourselves and update the prio to normal but the prio is not adjustable, maybe because a subticket is also high? Nevermind.
#17 Updated by okurz almost 4 years ago
- Description updated (diff)
Ok, I opened three new subtickets and therefore reopen the epic. About the "connections to OBS, e.g. SRs" I don't know what could be done here. Maybe we don't need anything there and just rely on "bug tracking" which could implicitly lead to parsing OBS SRs but that should be done by external scripts which at best are triggered by openQA events