action #10148

better notification and user feedback

Added by okurz about 4 years ago. Updated over 2 years ago.

Status:ResolvedStart date:13/11/2015
Priority:HighDue date:
Assignee:-% Done:

73%

Category:Feature requests
Target version:-
Difficulty:
Duration:

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 pluginNew

action #27844: backlink from openQA bug tracking to bugzillaNew

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


Related issues

Related to openQA Project - action #7476: Support comments in tests Resolved 12/05/2015
Related to openQA Project - action #13812: [tools][dashboard]openQA Dashboard ideas Workable 10/01/2017

History

#1 Updated by okurz about 4 years ago

  • Description updated (diff)

#2 Updated by oholecek about 4 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 about 4 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 about 4 years ago

#5 Updated by okurz about 4 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 almost 4 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 over 3 years ago

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

#10 Updated by okurz over 3 years ago

  • Related to action #13812: [tools][dashboard]openQA Dashboard ideas added

#11 Updated by dheidler about 3 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 about 3 years ago

  • Description updated (diff)

#13 Updated by okurz about 3 years ago

  • Status changed from New to In Progress

#14 Updated by coolo almost 3 years ago

  • Target version deleted (future)

#15 Updated by okurz over 2 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 2 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 2 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 2 years ago

  • Status changed from Resolved to In Progress

#19 Updated by coolo over 2 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