bunsen (re)design discussion #1: testrun & branch identifiers, testrun representation

[Keith Seitz]

On 3/14/22 10:24, Serhei Makarov wrote:
> Given the weak correspondence between Testrun/Testcase objects, we end
> up needing a set of explicit ser/de methods under the hood, just as
> with the JSON representation.

In Sept 2020, I played with this a bit, and I have old (probably stale)
patches lying around to let SQLite do the serialization. The patches
do nothing to replace the JSON or the presented data model.

I reported my initial findings here:

https://sourceware.org/pipermail/bunsen/2020q3/000034.html

If you'd like to peek at that work, I can send it along, but
it is probably quite bit-rot by now.

> My current understanding of the schema would be as follows:
> 
> - testruns (testrun_id, project, testlogs_commit_id)
> - ANALYSIS_testrun_kvs (testrun_id, key, value)
>    - For analysis results that annotate the original testrun.
> - testrun_kv_types (project, key, schema)
>    - We will probably need to store some 'schema' information like this.
> - testcases (testrun_id, name, outcome, subtest_id)
> - subtest_strs (subtest_id, subtest_text)
> 
> According to your vision, there would also need to be additional
> tables for analysis results which don't follow the format of testrun
> key-value annotations. Not relevant just yet, and we may need to
> decide a different schema for each category of analysis (diff, grid
> view, regression report, etc.).

I have a prototype schema just to record test data. Bunsen's git repo
is still used to store the actual .sum/.log files and provide commit
IDs to identify a particular testrun, i.e., no bunsne metadata.

Keith