Store junit report summary results in database so we can load top-level tests tab without file parsing

Problem to solve

Performance of the Pipeline page degraded after all junit report data was being parsed for the JUnit Reports tab. Before enabling this feature by default and building the JUnit errors + screenshots feature the ~performance issues need to be resolved.

Right now when the test tab is clicked on, and in order to generate the badge counter we need to parse the junit report files for all tests builds that generated junit reports. This takes a lot of time (50+ seconds to generate the badge counter the first time).

Intended users

• Sasha (Software Developer)

Further details

See the writeup in the parent epic.

Proposal

Limit the amount of data being processed on page load but give users a way to fetch the full data set if they want by:

• Using the established pattern of storing summarized results in a jsonb column per build
• The parsing of the JUnit XML report from the pipeline should be done in the background, and the results summarized in the ci_build_report_results table in a jsonb column.
• Use a query to summarize the results per build into the counter on the tests tab, as well as the top column as indicated in this MR !25199 (closed) (basically I think that we should finish implementing this MR with a small tweak), i.e. we should probably calculate the counter and the test summary at the top, and not store them separately.

Click here to see our current JSON schema proposal.

{
  "total_time": 0,
  "total_count": 0,
  "success_count": 0,
  "failed_count": 2,
  "errored_count": 0,
  "skipped_count": 0,
  "test_suite_results": [
    {
      "name": "job 0",
      "duration": 0,
      "success": 0,
      "failed": 1,
      "errored": 0,
      "skipped": 0,
      "total": 1
    },
    {
      "name": "job 1",
      "duration": 0,
      "success": 0,
      "failed": 1,
      "errored": 0,
      "skipped": 0,
      "total": 1
    }
  ]
}

Doing this (in the background?) should drastically reduce the load time of the badge on the pipeline page, and the initial load of the test tab. On clicking into a specific test group on the test tab the load time would still be fairly high as we would have to parse the junit.xml file then in order to give the granular results. Improving performance for individual junit report report loading will be handled in another issue after when another issue is completed.

Permissions and Security

Documentation

Availability & Testing

This will add one row per build that uploads a junit artifact in an append-only fashion (As indicated here: !25199 (comment 326136891)). We should eventually clean up these rows as they do not need to be kept around forever, and indeed can be regenerated as long as the junit artifacts exist. We also are not currently using them for reporting so we could figure out a summarization strategy for them at such time as we need to use them for reporting.

Testing required

• Unit test changes/additions
  • For new calculations for test badge
    • CRUD on DB jsonb storage of summary info
    • FE calculations of badge data
    • Possible revisit of end user status indicator for window between end of pipeline and test data being available
• End-to-end test
  • Not required for this iteration as it is core, but will be covereed in future test

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references