Skip to content

Only parse JUnit report for individual test suite when clicking into test suite on the pipeline page

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 on loading the test report tab, all JUnit test report XML files are parsed and returned to the frontend this causes the page to load slow initially. It's unlikely someone would want to consume all of the fine-grain test report data at once.

Intended users

Further details

See the writeup in the parent epic.

Proposal

After the companion issue to this is complete the summarized reports will be available from the database. If we implement an endpoint that parses and individual test report, we can call that instead when a specific test suite is clicked into. This should increase the performance overall as it's unlikely someone will click into every test suite.

sequenceDiagram
    participant U as User
    participant FE as Frontend
    participant BE as Backend
    U->>FE: Click onto pipeline page
    FE->>BE: Request test report summaries (async)
    BE->>FE: Return test report summaries from DB
    FE->>U: Render badge counter on test tab
    U->>FE: Click Test Tab
    FE->>U: Render test tab from summary data (No visual change from current)
    U->>FE: Click on single test suite
    FE->>BE: Request full report for single test suite
    BE->>FE: Parse XML report and return detailed report
    FE->>U: Render report for single test suite

This issue is for tracking the work necessary for completing "Request full report for single test suite" and "Render report for single test suite" from the above diagram.

The frontend will consume the endpoint created from #218723 (closed) in order to accomplish this.

Documentation

We should read through the documentation for this feature and remove any warnings that it might be slow on the tests tab once the performance has been validated. We should then perhaps add a warning that clicking into an individual test suite might be slow instead.

Availability & Testing

Testing needed:

  • Unit tests will need to be made for the endpoint and service level changes.
  • package-and-qa not necessary for this test. May be addressed in future E2E test

Risks:

  • User flow
    • If Users can click in and out of individual test suites somewhat rapidly
      • Are we able to stop parsing if a user exits the view before it is complete?
      • Will we be running multiple instances of parsing at the same time if a user quickly clicks through? Performance issue?
    • Users will need appropriate messaging including
      • While parsing
      • No record situation
      • Failures to parse

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

If after clicking on the test tab on a main gitlab project pipeline the page loads in less than 1000ms this will be a large success.

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by Zeff Morgan