Show reports (junit, code_quality, terraform, metrics) from a child pipeline in MR widget (#18311) · Epics · Epics · GitLab.org

Show reports (junit, code_quality, terraform, metrics) from a child pipeline in MR widget

### Release notes Description: Teams using parent-child pipeline architectures previously couldn't see test results, code quality reports, Terraform plans, and metrics from child pipelines in the merge request widget, forcing manual navigation through multiple pipelines to identify issues. This created inefficient workflows, especially for enterprise customers with monorepos and complex testing setups. We've now enhanced the merge request widget to display reports from child pipelines directly alongside parent pipeline results, with each child pipeline's reports presented individually and artifacts available for download. This provides developers with a unified view of all quality checks, significantly reducing time spent investigating failures and enabling faster, more efficient merge request reviews for teams leveraging GitLab's parent-child pipeline capabilities. Documentation: https://docs.gitlab.com/ci/testing/unit_test_reports/ ## Executive Summary Junit Reports are the[ top most artifacts](https://gitlab.com/gitlab-org/gitlab/-/issues/535259#note_2476927921) generated by pipelines and are very commonly used as a quality check during the merge process. The other reports (Code Quality, Terraform, Metrics) also have a reasonable usage are included in the epic for completeness for all major report types. Customers using parent-child pipelines cannot see test results from child pipelines in the parent pipeline view or Merge requests, forcing them to manually navigate through multiple child pipelines to identify failing tests. Teams waste significant time hunting for test failures across multiple pipeline levels instead of having a unified view. This impacts enterprise customers with monorepos and E2E testing teams ## ARR Impact [See internal thread](https://gitlab.com/groups/gitlab-org/-/epics/18311#note_2647315475) ## Proposed Scope 1. https://gitlab.com/gitlab-org/gitlab/-/issues/212894+s 2. https://gitlab.com/gitlab-org/gitlab/-/issues/363302+s 3. https://gitlab.com/gitlab-org/gitlab/-/issues/363303+s 4. https://gitlab.com/gitlab-org/gitlab/-/issues/363306+s 5. https://gitlab.com/gitlab-org/gitlab/-/issues/363307+s ## Acceptance Criteria 1. JUnit reports from the child pipelines should be displayed on the Merge Request Page individually 2. Artifacts should be downloadable from the Merge request page 3. Reports will not be merged - The dependencies (MR widget, dashboards, etc.) should still list all findings from the reports. But each report will be treated individually ## Limitations * [Nested child pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#nested-child-pipelines) will not be supported * [Combined Multi-Child Pipelines](https://docs.gitlab.com/ci/pipelines/downstream_pipelines/#combine-multiple-child-pipeline-configuration-files) will not be supported #### Engineering Assessment For 1 - Max Orefice has already done most of the work in a closed MR -[ gitlab#363302](https://gitlab.com/gitlab-org/gitlab/-/issues/363302) We should be able to re-open and polish this off #### Dependencies None. Per `@mfanGitLab`: > There is a sister issue for the parent epic: https://gitlab.com/groups/gitlab-org/-/epics/18377+ that is planned to be de-scoped because it'll be made obsolete: https://gitlab.com/groups/gitlab-org/-/epics/18377#note_2649633947 and has a lot of dependencies. > > This current issue can be done as a stand alone because we have the underlining foundation and infrastructure in place #### DRIs - **PM**: @rutshah  - **EM**: @drew  - **UX/PDM**: @veethika  - **Group(s)**: ~"group::pipeline execution"  - **Engineering Owner**: \[Stage level EM\] #### Initiative Driver - Product or Engineering? - [x] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment - These initiatives require a Product Priority label (P1/P2/P3) - They may also receive GTM tier labels (T1/T2/T3) for external communication - [ ] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components - These initiatives require an Engineering Priority label (E1/E2/E3) - They have internal visibility only and are not externally communicated - Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades #### Sizing and Funding (Optional) - **Size**: \[XS/S/M/L/XL\] - **Funding Status**: \[Funded/Partially funded/Not funded\] --- ### Hygiene Guidelines :bulb: \_See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/ ##### :one: Pre-Interlock - [x] Update epic description with all relevant information - [ ] Ensure all dependencies are identified - [ ] Apply appropriate labels (see below) - [x] Apply target delivery Milestone - [ ] Update interlock status as discussions progress (via label) ##### :two: Post-Interlock: once quarter begins - Update health status weekly (via label) - Document any newly identified risks or dependencies - Link to implementation epics/issues as work begins - Flag any scope or timeline changes immediately

epic