action #10148: better notification and user feedback
[tools][dashboard]Tracking open bugs based on product
Will be very good if we can have sort of list of open bugs on the
This will save a lot of time by asking people if the bug is open or I need to open one?
This will save some time on searching in bugzilla also...
If I found that a test is failing I can open a bug in put somewhere the link from this bug
so every other person can be sure that bug is present in the link is there.
Please let me know your opinions.
#3 Updated by dgutu over 4 years ago
It could be useful to have this comment/links to bugs here, in build overview
Comments are fine but you need to click on build number, test and go between this
a lot of times to understand if the bug is present for this failed test or not.
#8 Updated by okurz over 4 years ago
- Parent task set to #10148
this is related to #10148 and also #10212. For easier tracking of bugs that have been opened as the error has been confirmed in openqa, what do you think about using the "whiteboard" in bugs. It is already used to reference "ibs/obs" SR and the automatic notifications. We could add something to the whiteboard and then search for "whiteboard:'openqa:openqa.suse.de'" e.g. https://bugzilla.suse.com/buglist.cgi?quicksearch=whiteboard%3A%27openqa%3Aopenqa.suse.de%27&list_id=3095342 and "whiteboard:'openqa:openqa.opensuse.org'"
proposed format for whiteboard tag:
- '[…]' marks optional
- '<…>' encloses a variable to be replaced:
<instance>: the openqa instance on which this error has been found, e.g. 'openqa.suse.de' **
<test>: test number on openqa instance where the error was (first) found, e.g. last part from URL https://openqa.suse.de/tests/180205 **
<state>: state or state change of the test, e.g. 'failed', 'fixed', 'still_failing', 'stable', 'soft_failed'
Multiple tags are allowed.
- Initial failing test:
- Still failing in next build: former +
- Fixed in next build after that: former +
Search requests like these should work
#9 Updated by okurz over 4 years ago
management has to discuss and decide about whiteboard usage. Management was not asked yet.
Coming up with a list of all open bugzilla bugs which have "something to do with" openqa is actually easy, e.g. for internal openqa instance use
to combine it with a product, e.g. every open bug mentioning our openqa for product "SLES 12 SP1":
above but only "RESOLVED" ones, i.e. the ones that should be verified:
or add the name of a "test_module" in the query although this could be incomplete, e.g. if people only provide a full URL to the test, not the failed test module: