QA » openQA Project

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.

oholecek wrote:

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, ...)

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

about email notification, this could be interesting: http://search.cpan.org/~sharifuln/Mojolicious-Plugin-Mail-1.5/lib/Mojolicious/Plugin/Mail.pm

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

It might be worth to consider implementing browser triggered desktop notifications.

This tool fetches AMQP events, converts them into text and posts them on irc:
https://github.com/asdil12/suse_msg

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.