<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=285100) </details> <!--IssueSummary end--> ## Status Update (Oct 15th 2025) We developed a [proof-of-concept solution](https://gitlab.com/gitlab-org/gitlab/-/issues/562603#note_2697405762) using [CI Steps](https://docs.gitlab.com/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. ```yaml 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`](https://gitlab.com/gitlab-org/gitlab/-/issues/255983#proposal) is available would be to have a job that uses the [bridge jobs API](https://docs.gitlab.com/ee/api/jobs.html#list-pipeline-bridges) 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: ```yaml 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` ```yaml 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. ### Possible risks for ~"breaking change" For example - a parent pipeline triggers a child pipeline as: ```yaml 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