Project

General

Profile

Actions
Copy link

action #9544

closed

action #10148: better notification and user feedback

Build Tagging

Added by RBrownSUSE over 9 years ago. Updated about 9 years ago.

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

0%

Estimated time:

Description

user stories

  • As a QA SLE product manager I want to be able to review the results from older builds for documentation reasons like I am used to with testopia
  • As an openQA instance administrator I want to keep complete results only for "important builds" available in the live instance of openQA to use only reasonable amount of disk space

acceptance criteria

  • tagged builds have a special mark making them distinguishable from other builds (e.g. a star icon)
  • tagged builds (along with all test results) are not deleted by tidy up scripts

tasks

  1. tag icon on group overview on important build
  • Given 'group_overview' page
  • When user creates comment with tag:<build_ref>:important
  • Then on page 'group_overview' rendering icon is shown on important builds
  1. mark build as non-important build
  • Given a comment tag:<build_ref>:important exists on a job group comments
  • When user creates another comment with tag:<build_ref>:-important
  • Then on page 'group_overview' build <build_ref> is not shown as important
  1. no cleanup of important builds
  • Given a comment tag:<build_ref>:important exists on a job group comments
  • When GRU cleanup task is run
  • And job OR job_group OR asset linked to build which is marked as important by comment as above
  • Then "important builds" are skipped from cleanup

Optional

  1. save important flag in job groups table
  • Given a logged user and on the group_overview page of any product
  • When user creates comment with tag:<build_ref>:important
  • Then save flag important in database table job_groups

further explanation

We need to implement Build tagging so we can identify when product builds (and their test results) are important - betas, alphas, GMCs, etc

This needs to be shown on the Dashboard, as well as used by any tidy up scripts (we never want to delete any test results from tagged builds)

  • Every job within a build should be considered important -> no need to distinguish last jobs and retries or similar
  • No need to preserve the group overview as shown when the build was declared important -> no need to save information on "last jobs". Alternative approach to save this information: Save the rendered HTML page, e.g. could be saved as PDF/A and hashed

Related issues 2 (0 open — 2 closed)

Precedes openQA Project (public) - action #11052: Extensions on build and job taggingResolved2015-11-14

Actions
Copied to openQA Project (public) - action #11072: Always finish important buildsResolvedokurz2015-11-13

Actions
Actions
Copy link
 #1

Updated by RBrownSUSE over 9 years ago

  • Priority changed from Normal to High
Actions
Copy link
 #2

Updated by okurz over 9 years ago

Also, "important" builds should not be aborted during testing if a more recent (non-important) build shows up, e.g. triggered by maintenance update.

Actions
Copy link
 #3

Updated by okurz over 9 years ago

  • Category set to Feature requests
Actions
Copy link
 #4

Updated by okurz over 9 years ago

  • Description updated (diff)
Actions
Copy link
 #5

Updated by RBrownSUSE over 9 years ago

  • Parent task set to #10148
Actions
Copy link
 #6

Updated by okurz about 9 years ago

  • Description updated (diff)

Two simple approaches of what I can think of:

  1. Just post the ISO with a non-number build start character so that we can distinguish and match on this, e.g. "Build0123" vs. "Buildalpha1" or "BuildGMC". If we only declare a build, e.g. "Build0234" as "alpha1" after testing in openQA I don't see a problem with copying the ISO once more with the new name
  2. We could tag a build using a comment on the group_overview page, e.g. "tag:Build0234:important", which could be read when just rendering the group overview page to also show this build even if it is older than the two weeks we use currently as a display limit

So what exactly where the user stories you had in mind when wishing for this feature? I am not sure we are on the same page here.

And where exactly are old screenshots cleaned up?

WDYT?

Actions
Copy link
 #7

Updated by okurz about 9 years ago

  • Description updated (diff)

after discussion with RBrownSUSE.

Updated user stories in description.

okurz wrote:

  1. Just post the ISO with a non-number build start character …

Not a good idea as this would induce a high system load and long waiting time when turnaround time is crucial, e.g. imagine providing an "urgent fix" as "RCi+1", but openQA is busy re-iterating "RCi" which is equivalent to a previous build except for the changed name.

  1. We could tag a build using a comment on the group_overview page, e.g. "tag:Build0234:important", which could be read when just rendering the group overview page to also show this build even if it is older than the two weeks we use currently as a display limit

Should be a viable approach. openQA does not have a "build" as an object so we can not store any information on the build anyway. So I think it should be ok to store something in a job group or the comments within a job group.

And where exactly are old screenshots cleaned up?

I still can't find a good reference in code. I see "lib/OpenQA/WebAPI/Controller/Admin/Needle.pm::delete" but this should be called only from the UI and only delete needles.

What looks interesting is "lib/OpenQA/Schema/Result/JobModules.pm::save_details" which actually calls unlink($self->job->result_dir . "/" . $d->{screenshot}->{name});

So is this our "cleanup"? Although the name "save_details" might not be the best when it deletes stuff. It is acting on 'job->result_dir' so I assume it is not working in the testresults dir.

Actions
Copy link
 #8

Updated by RBrownSUSE about 9 years ago

I like the updated description with one caveat

tag:<build_ref>:important does not include sufficient information

Would be nice to also include <milestone_ref> so we know WHY it is important ..was it an RC1, RC2, etc

Will be needed to be searched upon at some point I'm sure - we will want to be able to search for the RC1 results of a product retroactively

Actions
Copy link
 #9

Updated by okurz about 9 years ago

  • Assignee set to okurz
Actions
Copy link
 #10

Updated by okurz about 9 years ago

  • Copied to action #11052: Extensions on build and job tagging added
Actions
Copy link
 #11

Updated by okurz about 9 years ago

  • Copied to deleted (action #11052: Extensions on build and job tagging)
Actions
Copy link
 #12

Updated by okurz about 9 years ago

  • Precedes action #11052: Extensions on build and job tagging added
Actions
Copy link
 #13

Updated by okurz about 9 years ago

  • Status changed from New to Feedback

PR ready: openQA gh#591

The PR covers both US, both AC, the three mandatory tasks but not the optional one.

Also created another ticket #11052 for everything that is considered "out of scope" for the current feature request, e.g. other cool ideas to follow on.

Actions
Copy link
 #14

Updated by okurz about 9 years ago

Actions
Copy link
 #15

Updated by okurz about 9 years ago

Actions
Copy link
 #16

Updated by okurz about 9 years ago

  • Status changed from Feedback to Resolved

PR merged and active on osd, e.g. see http://openqa.suse.de/group_overview/25

Actions
Copy link

Also available in: Atom PDF