Standalone parser notes

This page has information about the project to de-couple Fuego's test log parser, to make it a standalone program.

Neil Williams had some good feedback (some of it negative) on the automated testing mailing list.

This page seeks to organize that content, and capture ideas about the process of making Fuego's parser standalone.

vision [edit section]

Create a standalone test program output parser, that can be used by multiple test systems, so that parsing is not baked into each test system.

Let it develop on its own, independent of a particular test system.

input [edit section]

Run artifacts from a test program

There can be multiple channels of information to extract data from during a test program run.

format, markers or tags [edit section]

output [edit section]

Standardized output in multiple formats:

current dependencies on Fuego [edit section]

Miscelaneous notes [edit section]

Tim's notes [edit section]

Up to Fuego 1.5 we invoke the parser with:

(with a whole lot of Fuego-specific environment variables).

I think it would be good to refactor this, so that the fuego core (functions.sh) calls a single program, indicating the test, the log file, and a parser name. Many fuego parsers could be combined by declaring a single regex pattern in the fuego_test.sh (similar to what is done with log_compare).

So, something like the following instead:

or

Daniel's notes [edit section]

I was thinking about a new python library called (e.g.: "fuegoparse") that you can use from any project (e.g.: install it with pip3) and also be called from the command line.

Example usage as a library:

Example as a command:

Other output formats could be TAP, KernelCI, Squad, Junit, etc.

This could become a whole new project (the first spinoff of the Fuego project!).

We also need to think about isolating other parts (cross-build, dependency checks, transport abstractions), so they can be reusable. And finally be able to say that Fuego is just glue code that puts all those parts together.