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.
Category:
Feature requests
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¶
- Description updated (diff)
- Target version changed from Ready to future
- Status changed from Workable to Feedback
- Assignee set to okurz
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.
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
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.
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" :)
- 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
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.
- Status changed from Workable to In Progress
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
- Related to action #94060: unstable test t/ui/18-tests-details.t added
Also available in: Atom
PDF