Project

General

Profile

Actions
Copy link

action #9544

closed

action #10148: better notification and user feedback

Build Tagging

Added by RBrownSUSE about 9 years ago. Updated over 8 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

  2. 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

  3. 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 about 9 years ago

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

Updated by okurz about 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 about 9 years ago

  • Category set to Feature requests
Actions
Copy link
 #4

Updated by okurz about 9 years ago

  • Description updated (diff)
Actions
Copy link
 #5

Updated by RBrownSUSE about 9 years ago

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

Updated by okurz almost 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 almost 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 almost 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 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 almost 9 years ago

  • Assignee set to okurz
Actions
Copy link
 #10

Updated by okurz almost 9 years ago

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

Updated by okurz almost 9 years ago

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

Updated by okurz almost 9 years ago

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

Updated by okurz almost 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 almost 9 years ago

Actions
Copy link
 #15

Updated by okurz almost 9 years ago

Actions
Copy link
 #16

Updated by okurz over 8 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