Project

General

Profile

Actions

action #91773

closed

QA - coordination #91646: [saga][epic] SUSE Maintenance QA workflows with fully automated testing, approval and release

coordination #89062: [epic] Simplify review for SUSE QAM

Automatic replacement of openQA job URLs preview of openQA size:M

Added by okurz over 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
Feature requests
Target version:
Start date:
2021-04-26
Due date:
% Done:

0%

Estimated time:

Description

Motivation

openqa-investigate provides comments in openQA jobs. To see the results one needs to follow the URLs. An immediate overview could be achieved if openQA could automatically replace openQA job URLs when displaying by a status display, e.g. the green/yellow/red bubble icon same as we have in /tests, /tests/overview, the "next & previous" job list, etc.

Acceptance criteria

  • AC1: Whenever openQA job URLs are rendered in an openQA instance the according job status is visible on the same page
  • AC2: Feature switch exists

Out of scope

  • Client side solution

Suggestions

  • Assuming we already render comments asynchronously I think putting in the job status whenever we render an openQA job url should be ok performance-wise.
  • As I am talking about putting the job status within the text comment that could be either just text, like "(passed)", "(soft-failed)" or maybe also nice colored unicode symbols :)
  • Add a feature switch that we can disable on performance problems

Related issues 2 (1 open1 closed)

Related to QA - coordination #94105: [epic] Use feedback from openqa-investigate to automatically inform on github pull requests, open tickets, weed out automatically failed testsBlockedokurz2021-07-20

Actions
Related to QA - action #95746: Identify likely "sporadic" openQA tests with "openqa-investigate" size:MResolvedXiaojing_liu2021-07-20

Actions
Actions #1

Updated by okurz over 3 years ago

  • Related to coordination #94105: [epic] Use feedback from openqa-investigate to automatically inform on github pull requests, open tickets, weed out automatically failed tests added
Actions #2

Updated by okurz over 3 years ago

  • Target version changed from future to Ready
Actions #3

Updated by ilausuch over 3 years ago

  • Subject changed from Automatic replacement of openQA job URLs preview of openQA to Automatic replacement of openQA job URLs preview of openQA size:M
  • Description updated (diff)
  • Status changed from New to Workable
Actions #4

Updated by mkittler over 3 years ago

In the meeting we said a client-side solution would be difficult because we needed to replace the URLs after the overall page has loaded and doing so would be disturbing as it affects the layout. However, it could be implemented in a way that before the job status is known a loading circle is rendered which is replaced by a status circle of the same size when the status is known and the job's name would only be added as tooltip. The link text could be folded to "job#1234" from the beginning. This way the layout would not change suddenly.

Actions #5

Updated by livdywan over 3 years ago

mkittler wrote:

In the meeting we said a client-side solution would be difficult because we needed to replace the URLs after the overall page has loaded and doing so would be disturbing as it affects the layout. However, it could be implemented in a way that before the job status is known a loading circle is rendered which is replaced by a status circle of the same size when the status is known and the job's name would only be added as tooltip. The link text could be folded to "job#1234" from the beginning. This way the layout would not change suddenly.

So rather than 🔴kde-wayland@aarch64 it would be 🔴job#1868683?

If we decide we can't render the name I would rather stick to the URL since job# is not a common way to refer to jobs. So it would be 🔴https://openqa.opensuse.org/tests/1868683.

That said I'd strongly prefer rendering the name somehow. We could show empty comments until we have the job names (or time out and show it verbatim).

Actions #6

Updated by okurz over 3 years ago

cdywan wrote:

[…]
If we decide we can't render the name I would rather stick to the URL since job# is not a common way to refer to jobs. So it would be 🔴https://openqa.opensuse.org/tests/1868683.

That said I'd strongly prefer rendering the name somehow.

Why care about the name? I think only the job result is important for now. That should make implementation easier.

We could show empty comments until we have the job names (or time out and show it verbatim).

Why not just add the job status icon after the URL whenever we managed to receive that data?

Actions #7

Updated by tinita about 3 years ago

  • Status changed from Workable to In Progress
  • Assignee set to tinita
Actions #8

Updated by tinita about 3 years ago

While rendering the job states/results in javascript and trying to reuse existing code, I stumbled upon a little bug in the activity view:
https://github.com/os-autoinst/openQA/commit/203d1d7d3289c2007b724c8e468dd42299772f12#diff-fae8284b51d426d67a2d9bb8590c1f8e06151d909a34a7e67f36bdc2038907e9R335

Running and Scheduled won't be rendered as they are inside a if (job.state === 'done')

Actions #9

Updated by tinita about 3 years ago

I think I found another bug.
The activity view is supposed to poll jobs which are not yet finished and display the updated status.
However, the code

https://github.com/os-autoinst/openQA/blob/master/assets/javascripts/openqa.js#L377

  // continue polling for job state updates until the job state is done
  if (job.state !== 'done') {
    setTimeout(updateTestState, 5000);
  }

Does not pass any arguments to updateTestState.
If I change it to

  // continue polling for job state updates until the job state is done
  if (job.state !== 'done') {
    setTimeout(function() { updateTestState(job, name, timeago, reason) }, 5000);
  }

Then it calls the function repeatly, but that doesn't do the http request.

Actions #10

Updated by tinita about 3 years ago

PR for fixing the status icons in activity view: https://github.com/os-autoinst/openQA/pull/4175

Actions #11

Updated by okurz about 3 years ago

  • Related to action #95746: Identify likely "sporadic" openQA tests with "openqa-investigate" size:M added
Actions #12

Updated by tinita about 3 years ago

  • Status changed from In Progress to Feedback
Actions #13

Updated by okurz about 3 years ago

PR merged

Actions #14

Updated by okurz about 3 years ago

  • Status changed from Feedback to Resolved

I can see the feature working just fine on o3, e.g. in comments like https://openqa.opensuse.org/tests/1916101#comments . So far no negative performance impact was observed. Great work!

Actions

Also available in: Atom PDF