Allow job in upstream pipeline to reference artifacts from a downstream pipeline
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Status Update (Oct 15th 2025)
We developed a proof-of-concept solution using CI Steps. However, this approach has limitations as it only supports docker executor types. We validated it with customers and most of them can only use the solution with support available for other executor types. Given these constraints and our current development priorities, we forecast prioritizing this feature for roadmap delivery in the mid-to-late calendar year 2026.
Workaround
https://gitlab.com/poffey21/child-artifacts
Problem
Let's imagine a scenario where a parent pipeline triggers multiple child pipelines but then, in a later stage it requires to fetch artifacts from the child pipelines.
child-a:
stage: build
trigger:
include: child-a.yml
strategy: depend
child-b:
stage: build
trigger:
include: child-b.yml
strategy: depend
test:
stage: test
script:
- # use artifacts from child pipeline triggered by child-a
- # use artifacts from child pipeline triggered by child-b
Today one way to do that after needs:pipeline
is available would be to have a job that uses the bridge jobs API to list all the bridge jobs and related downstream pipelines. Iterate over them and set variables using dotenv artifact for each downstream pipeline, then test
job could use:
needs:
- pipeline: $DOWNSTREAM_PIPELINE_A
job: job-1
- pipeline: $DOWNSTREAM_PIPELINE_B
job: job-1
This seems very cumbersome and given that we always map a downstream pipeline to an upstream bridge job we could provide some syntactic sugar to facilitate that.
Proposal idea
Maybe we could simplify that by having a syntax like needs:pipeline_from
test:
stage: test
script:
- # use artifacts from child pipeline triggered by child-a
- # use artifacts from child pipeline triggered by child-b
needs:
- pipeline_from: child-a
job: job-1
- pipeline_from: child-b # must accept only a bridge job and not a regular job
job: job-1
which allows to reference the downstream pipeline relative to a bridge job and could potentially work for both parent-child pipelines as well as multi-project pipelines.
breaking change
Possible risks forFor example - a parent pipeline triggers a child pipeline as:
build:
stage: build
script: echo hello > artifact.txt
artifacts:
paths: [artifact.txt]
test:
stage: test
trigger:
include: [child.yml]
strategy: depend
deploy:
stage: deploy
script: cat artifact.txt
The deploy
job does something with the artifact from build
. If we suddenly expose in deploy
all artifacts from the child pipeline created by test
and the child pipeline used to create an artifact.txt
for internal use, the deploy
job could see the artifacts.txt
replaced from build
.
Example Use Cases
Security Testing & Reporting
- Running security scans in child pipelines, but needing results to appear in the parent pipeline
- Having security findings from child pipelines reported in merge requests
- Allowing security reports to be visible in the parent project's security dashboard
Cross-Platform Testing
- Building and testing for different OS, architecture, or language versions
- Triggering parallel builds with different configurations
- Collating test results from all platforms