Project

General

Profile

action #92746

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 5 months ago. Updated 4 months ago.

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

0%

Estimated time:
Difficulty:

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

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

History

#1 Updated by okurz 5 months ago

  • Description updated (diff)

#2 Updated by okurz 5 months ago

  • Target version changed from Ready to future

#3 Updated by tinita 5 months 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

#4 Updated by okurz 5 months ago

  • Status changed from Workable to Feedback
  • Assignee set to okurz

#5 Updated by mkittler 5 months 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.

#6 Updated by okurz 5 months 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

#7 Updated by tinita 5 months 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.

#8 Updated by okurz 5 months 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" :)

#9 Updated by okurz 5 months 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

#10 Updated by mkittler 5 months ago

  • Assignee set to mkittler

#11 Updated by mkittler 5 months 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.

#12 Updated by mkittler 4 months ago

  • Status changed from Workable to In Progress

#13 Updated by mkittler 4 months ago

  • Status changed from In Progress to Feedback

#14 Updated by mkittler 4 months ago

  • Status changed from Feedback to Resolved

Works on OSD

#15 Updated by okurz 4 months ago

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

Also available in: Atom PDF