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
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 (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 as those pipelines will show a pipeline for the "child" in the Pipelines list view of a project.
Intended users
- Rachel (Release Manager)
- Parker (Product Manager)
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Sam (Security Analyst)
- Simone (Software Engineer in Test)
Further details
This issue is part of a more comprehensive solution detailed in &3156 (closed). 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
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 - #335447. See table below for the full list.
So we need to address these 2 groups separately:
- Include reports from child pipelines for those that are not blocked
✅ #362876 (closed) - Address blocking issue
❌ #335447 - Include reports from child pipelines that are now unblocked
blocked? | report_type |
---|---|
cobertura | |
coverage_report | |
junit | |
codequality | |
accessibility | |
terraform | |
license_scanning | |
metrics | |
api_fuzzing | |
container_scanning | |
coverage_fuzzing | |
dast | |
dependency_scanning | |
sast | |
secret_detection | |
browser_performance | |
load_performance |
Caveats:
- Other than on the MR, the following reports (
junit
,code_quality
,license_scanning
) are used in a few other places that don't uselatest_report_builds
, so in those places, the reports from child pipeline would not be included. - Security dashboard is exposed 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. - Projects::LicensesController uses a different method to query the report, so it would still not include the child pipeline report
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Ultimate / Gold Buyer
Is this a cross-stage feature?
Links / references
Blocked by &6302
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.