Project

General

Profile

Actions

action #92746

closed

coordination #39719: [saga][epic] Detection of "known failures" for stable tests, easy test results review and easy tracking of known issues

coordination #19720: [epic] Simplify investigation of job failures

Log viewer in openQA webUI with color parsing

Added by okurz almost 3 years ago. Updated almost 3 years ago.

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

0%

Estimated time:

Description

Motivation

Log files like autoinst-log.txt are often crucial for reviewing test results. openQA does not yet have a "log viewer", it only provides a download and browsers can choose to show logs verbatim. Compare to gitlab in https://gitlab.suse.de/openqa/auto-review/-/jobs/345765/raw showing the raw log with control codes from both code that comes from us as well as gitlab internal code doing the same in comparison to a nice log viewer https://gitlab.suse.de/openqa/auto-review/-/jobs/345765 that shows color for both parts again, e.g. nice colorful autoinst-log.txt . We also have a separate video viewer since https://github.com/os-autoinst/openQA/pull/2605 so we can try a similar approach for logs now

Acceptance criteria

  • AC1: autoinst-log.txt accessible over the openQA webUI show colors based on the control characters included in autoinst-log.txt
  • AC2: Raw unaltered logs can still be accessed over the webUI for download

Suggestions


Related issues 1 (0 open1 closed)

Related to openQA Project - action #94060: unstable test t/ui/18-tests-details.tResolvedmkittler2021-06-152021-07-01

Actions
Actions #1

Updated by okurz almost 3 years ago

  • Description updated (diff)
Actions #2

Updated by okurz almost 3 years ago

  • Target version changed from Ready to future
Actions #3

Updated by tinita almost 3 years ago

There is a module for turning control characters into HTML, I've used it in the past: https://metacpan.org/pod/HTML::FromANSI::Tiny

Actions #4

Updated by okurz almost 3 years ago

  • Status changed from Workable to Feedback
  • Assignee set to okurz
Actions #5

Updated by mkittler almost 3 years ago

Intuitively I would have implemented this on the client side. (Why keep our servers busy for something one can likely do with ease in JavaScript? A JavaScript solution has likely faster loading times.)

In a private project I've already tried xterm.js. It is very performant but also more of a terminal than a log view and searching and resizing is a bit inconvenient. However, there are likely JavaScript libraries out there which would fit our use-case.

Actions #6

Updated by okurz almost 3 years ago

Sure, we don't need to use server side perl solutions. I just wanted to submit the packages in case we want to use them nevertheless. I would also favor a server side solution

Actions #7

Updated by tinita almost 3 years ago

Client side also makes sense in this case.

Regarding keeping our servers busy: I have good experiences with caching (in redis, memcached, etc.). For example we are doing a lot of SQL queries on some pages, where we actually wouldn't have to redo those queries on every request (because the data doesn't change or because it would be ok to show slightly outdated data).
but that's a different story.

Actions #8

Updated by okurz almost 3 years ago

tinita wrote:

Regarding keeping our servers busy: I have good experiences with caching (in redis, memcached, etc.). For example we are doing a lot of SQL queries on some pages, where we actually wouldn't have to redo those queries on every request (because the data doesn't change or because it would be ok to show slightly outdated data).
but that's a different story.

https://progress.opensuse.org/projects/openqav3/issues/new is the place for "different story" :)

Actions #9

Updated by okurz almost 3 years ago

  • Status changed from Feedback to Workable
  • Assignee deleted (okurz)
  • Target version changed from future to Ready

Both SRs accepted. This server side approach can be taken as secondary if the JS path fails

Actions #10

Updated by mkittler almost 3 years ago

  • Assignee set to mkittler
Actions #11

Updated by mkittler almost 3 years ago

Seems like there a a lot of JS libraries out there: https://www.npmjs.com/search?q=keywords%3Aansi&ranking=popularity
Maybe I should go with the most popular option - which would be in some way to create my own library and add it to npm :-)

By the way, it looks like CodeMirror (which we would already be using) doesn't support ANSI formatting.

Actions #12

Updated by mkittler almost 3 years ago

  • Status changed from Workable to In Progress
Actions #13

Updated by mkittler almost 3 years ago

  • Status changed from In Progress to Feedback
Actions #14

Updated by mkittler almost 3 years ago

  • Status changed from Feedback to Resolved

Works on OSD

Actions #15

Updated by okurz almost 3 years ago

  • Related to action #94060: unstable test t/ui/18-tests-details.t added
Actions

Also available in: Atom PDF