action #10212


action #10148: better notification and user feedback

labels and badges for builds

Added by okurz about 8 years ago. Updated almost 8 years ago.

Feature requests
Target version:
Start date:
Due date:
% Done:


Estimated time:


User stories

US1, US3, US5

acceptance criteria

  • AC1: A label can be made visible to every test bubble in the build overview page
  • AC2: If at least all failed tests are labeled, a badge is displayed on the job group overview page


  • Add an optional simple one-letter/symbol link/badge/label to build overview for every test
  • Add the label based on data in the test itself, e.g. comment present see
  • optional: Add description field to test, also see
  • Add label based on description
  • Add badge to build on group overview page based on labels in the build overview

ask okurz for further details

further details

  • label: symbol/text that can be set by a user
  • can be made visible: By any mean, e.g. writing a comment, clicking a button, filling a text field, using a CLI tool
  • badge: should be a symbol showing that a review has been completed on a build, e.g. a star or similar

Regarding AC2 it might be hard to label all failing tests in a build as many of them might have a common cause and it would be tedious to select every failing test if we know the reason is the same. It might help if a label or description is preserved for a build that is still failing like in The problem here is described in #10212#note-12 "koalas are not openQA first class citizens" means a database query for every job in one build would take too long when generating the overview page so this should be done in a GRU task or at the completion time of each job.

In discussions I mentioned there should be a "fail reason description" which is exactly what coolo mentioned here I propose we should have a test description field, e.g. a field just below the "Overall summary" which we can edit to describe the current state, add bug links, describe who is working on it, etc. (see for an example)

A label for each scenario would help to follow the history of test runs within each scenario but it can not automatically identify the same problem in a different scenario, e.g. same problem on two different architectures or same problem in RAID0 and gnome even though it is not related to RAID. So this still needs a human interaction and reasoning. A "common failure analyzer" that remembers failure causes can help which would provide suggestions to a test reviewer or list on another view if the same issue is found in different scenarios.

Related issues 1 (0 open1 closed)

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


Also available in: Atom PDF