Read child pipeline artifacts for MR reports (Promoted)
### Release notes
When using parent-child pipelines, you are unable to trace those artifacts generated in the downstream pipeline to the parent. Now, GitLab supports reading pipeline artifacts for merge request reports, enabling you to efficiently view and consume test results in your pipelines.
### Problem to solve
<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
When a user generates a dynamic pipeline, the artifacts from the child (dynamically created pipeline) are not brought back to the parent pipeline which prevents GitLab's most valuable page, the Merge Request page, from properly displaying results gathered from the dynamically created child pipeline.
This is aimed to address [Parent/Child Pipelines](https://docs.gitlab.com/ee/ci/parent_child_pipelines.html) (including Dynamic Pipelines) given that they never receive a Pipeline in the Pipelines list view of a project.
This is **not** dealing with [Multi-Project Pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html) as those pipelines will show a pipeline for the "child" in the Pipelines list view of a project.
### Intended users
* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
### Further details
<!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. -->
This issue is part of a more comprehensive solution detailed in https://gitlab.com/groups/gitlab-org/-/epics/3156. Visibility of child artifacts for parent pipelines is a key component of solving for separation of duties within CI/CD pipelines.
**Things Able to be Generated but not Reported On within Dynamically-created Child Pipeline**:
**Ultimate**
* `artifacts:reports:sast`
* `artifacts:reports:dependency_scanning`
* `artifacts:reports:container_scanning`
* `artifacts:reports:dast`
* `artifacts:reports:license_scanning`
**Premium**
* `artifacts:reports:performance` - Load/Browser
* `artifacts:reports:metrics`
**Free**
* `artifacts:reports:codequality`
* Code Coverage detection for the parent pipeline / MR, although it will be displayed for a child job.
* `artifacts:reports:junit`
* `artifacts:reports:cobertura`
### Proposal
<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
When a dynamically-generated pipeline is created and the parent `trigger:` job has a `strategy: depend` applied, all artifacts from the child pipelines are retrieved and utilized for reporting purposes - specifically but not limited to within the Merge Request page.
Some of the report artifacts are blocked by multiple report performance - https://gitlab.com/gitlab-org/gitlab/-/issues/335447. See table below for the full list.
So we need to address these 2 groups separately:
1. Include reports from child pipelines for those that are not blocked :white_check_mark: https://gitlab.com/gitlab-org/gitlab/-/issues/362876
1. Address blocking issue :x: https://gitlab.com/gitlab-org/gitlab/-/issues/335447
1. Include reports from child pipelines that are now unblocked
| blocked? | report_type |
|----------|---------------------|
| ✅ | cobertura |
| ✅ | coverage_report |
| :warning: | junit |
| :warning: | codequality |
| ✅ | accessibility |
| ✅ | terraform |
| :warning: | license_scanning |
| ✅ | metrics |
| ✅ | api_fuzzing |
| ✅ | container_scanning |
| ✅ | coverage_fuzzing |
| ✅ | dast |
| ✅ | dependency_scanning |
| ✅ | sast |
| ✅ | secret_detection |
| ❌ | browser_performance |
| ❌ | load_performance |
Caveats:
1. Other than on the MR, the following reports (`junit`, `code_quality`, `license_scanning`) are used in a few other places that don't use `latest_report_builds`, so in those places, the reports from child pipeline would not be included.
1. Security dashboard is [exposed](https://gitlab.com/gitlab-org/gitlab/blob/84a5101ef22df91049a580fda312483ba959a9b3/ee/app/presenters/ee/ci/pipeline_presenter.rb#L9) based on `latest_report_artifacts`. So there could be situation where the MR shows the security reports from child pipeline, but the security dashboard is not exposed.
1. Projects::LicensesController uses a different method to query the report, so it would still not include the child pipeline report
### Permissions and Security
<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?-->
### Documentation
<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->
### Availability & Testing
<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.
What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?
Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
* Unit test changes
* Integration test changes
* End-to-end test change
See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning -->
### What does success look like, and how can we measure that?
<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
### What is the type of buyer?
Ultimate / Gold Buyer
### Is this a cross-stage feature?
<!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features -->
### Links / references
Blocked by https://gitlab.com/groups/gitlab-org/-/epics/6302
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
issue