Project

General

Profile

action #10148

better notification and user feedback

Added by okurz over 5 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Feature requests
Target version:
-
Start date:
2015-11-13
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:

Description

various ideas

  • 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,
    • DONE: a tag "I will take care of this" for failing tests -> #10212
    • DONE: references to reported bugs in failing tests -> #10212
    • connections to OBS, e.g. SRs

further notes and references


Subtasks

action #9544: Build TaggingResolvedokurz

action #10212: labels and badges for buildsResolvedokurz

action #10188: [tools][dashboard]Tracking open bugs based on productResolveddheidler

action #10622: Make comments editableResolvedmkittler

action #10632: comment edit window should be shown on top of commentsRejected

action #10672: notifications about new review comments availableResolveddheidler

action #15086: AMQP Message PluginResolveddheidler

action #15902: amqp host for o.oResolvedcoolo

action #27841: Improve documentation and usage examples of AMQP pluginRejectedokurz

action #27844: backlink from openQA bug tracking to bugzillaRejectedokurz

action #27847: IRC bot with updates about test runs, e.g. if builds are finishedResolvedokurz


Related issues

Related to openQA Project - action #7476: Support comments in testsResolved2015-05-12

Related to openQA Project - coordination #13812: [epic][dashboard] openQA Dashboard ideasNew2017-01-10

History

#1 Updated by okurz over 5 years ago

  • Description updated (diff)

#2 Updated by oholecek over 5 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.

#3 Updated by RBrownSUSE over 5 years ago

  • Priority changed from Normal to High

Upgrading Prio to high, specifically for the requirement of providing faster feedback to specific developers related to tests

#4 Updated by okurz over 5 years ago

#5 Updated by okurz over 5 years ago

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

#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

#8 Updated by dheidler almost 5 years ago

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

#10 Updated by okurz almost 5 years ago

#11 Updated by dheidler over 4 years ago

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

#12 Updated by okurz over 4 years ago

  • Description updated (diff)

#13 Updated by okurz over 4 years ago

  • Status changed from New to In Progress

#14 Updated by coolo about 4 years ago

  • Target version deleted (future)

#15 Updated by okurz almost 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.

#16 Updated by coolo over 3 years ago

  • Status changed from In Progress to Resolved

IMO this epic is done - for specific enhancements, file specific tickets

#17 Updated by okurz over 3 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

#18 Updated by okurz over 3 years ago

  • Status changed from Resolved to In Progress

#19 Updated by coolo over 3 years ago

  • Status changed from In Progress to Resolved

It can always be better - but I don't need a High priority issue polluting the backlog just because there are some minor improvements possible.

Also available in: Atom PDF