Bitbucket Parent and Child Pipeline Artifacts

How do you share artifacts between parent and child pipelines?

In Bitbucket Pipelines, declare artifacts: input: and artifacts: output: on a type: pipeline step. Inputs make uploaded parent artifacts available to the child; outputs make child artifacts available to later steps in the parent. The producer still needs to upload the artifact.

For example, a parent can build an application, pass that build to a child test pipeline, and receive a test report back. Define the file contract in both directions, then verify the paths and expected report. The official cross-pipeline artifact guide and complete YAML example below show the pattern.

I want to tell you about a small Bitbucket Pipelines update that quietly solves a problem I've been hearing about from build engineers for the better part of a year.

Last fall, one of our DevOps clients sat me down to walk me through what he called "the workaround tour." His team had recently restructured their CI/CD into parent and child pipelines — modular, reusable, beautifully separated by concern. Build pipeline up top, test pipelines hanging below, deployment pipelines after that. Textbook architecture. Until you needed to actually pass something between them.

"So I just upload to S3 between every step," he said, gesturing at a diagram with three arrows labeled "S3" pointing in suspiciously identical directions. "And then I download it on the other side."

He wasn't proud of it. Nobody is when their CI/CD architecture has a side gig in object storage. But until very recently, that was the cleanest way to share a build artifact between a parent pipeline and the child pipeline it had triggered. A whole layer of duct tape that existed only because the feature underneath wasn't quite finished.

That layer just got retired. Atlassian announced that Bitbucket Pipelines now lets you share artifacts directly between parent and child pipelines — and as someone who spends a meaningful portion of every week elbow-deep in client CI/CD configurations, I want to walk you through why this seemingly small release is actually a quietly significant turning point.

The Family Tree, Briefly

For anyone who hasn't waded into parent/child pipelines yet, here's the short version. Bitbucket Pipelines lets you define a step in a pipeline that doesn't run a script — instead, it triggers an entire other pipeline. The triggering pipeline is the parent. The triggered pipeline is the child. The architecture lets you break complex CI/CD logic into modular pieces that can run in parallel, get reused across projects, and stop turning your YAML into the kind of file people apologize for before opening.

It's a beautiful pattern. And like most beautiful patterns, it had a sharp edge: parents and children couldn't share files. The parent could build a JAR, but the child running tests against that JAR had to fetch it from somewhere else. The child could produce a coverage report, but the parent couldn't read it back. So teams improvised. They used external storage. They restructured their pipelines to avoid the handoff. They lived with redundant build steps. They Slack-messaged each other about it sometimes.

Atlassian closed the gap. You can now declare an artifacts block on a child-pipeline step that lists what gets uploaded into the child and what gets downloaded back from it. Files flow both directions. The whole "I'll just put it in S3" workaround has been quietly demoted to "remember when we had to do that?"

How Bitbucket Pipelines artifacts move between parent and child pipelines

The current cross-pipeline artifact documentation uses artifacts: input: for files pushed from the parent into the child and artifacts: output: for files pulled back into the parent. The parent defines the contract; the child reads the input like a normal file and publishes its output with the standard artifacts block.

Complete parent/child example

image: node:20

pipelines:
  branches:
    main:
      - step:
          name: Build application
          script:
            - npm ci
            - npm run build
            - tar -czf app.tar.gz dist/
          artifacts:
            - app.tar.gz

      - step:
          name: Security scan
          type: pipeline
          custom: security-scan
          artifacts:
            input:
              - app.tar.gz
            output:
              - security-report.json

      - step:
          name: Review report
          script:
            - test -f security-report.json
            - cat security-report.json

  custom:
    security-scan:
      - step:
          name: Scan build
          script:
            - test -f app.tar.gz
            - tar -xzf app.tar.gz
            - ./scripts/generate-security-report.sh > security-report.json
          artifacts:
            - security-report.json

What you should see: the build step creates app.tar.gz; the child receives that exact artifact; the child creates security-report.json; and the final parent step can read the returned report without S3, a second build, or another handoff service.

One documentation wrinkle: Atlassian's current child-pipeline step-options page still shows the older upload/download terminology, while its newer parent/child and cross-pipeline artifact pages document input/output. Before pasting this into a production pipeline, validate the accepted keys against the configuration reference for your workspace. That inconsistency is precisely why copying an old snippet from a search result is a bad deployment strategy.

Artifact rules that cause the most failures

• The file has to exist inside BITBUCKET_CLONE_DIR. If your build writes outside the clone directory, it will not be captured as an artifact.
• Keep each artifact under 1 GB. Standard Bitbucket artifact limits still apply across the parent/child boundary.
• Artifacts expire after 14 days. Use external storage when the output is a release asset or record you need to retain longer.
• A missing input does not necessarily fail the child trigger. Guard required files with a check such as test -f app.tar.gz so the failure happens clearly and early.
• Use shared artifacts for files another step needs. Scoped artifacts are better for logs, screenshots, and failure evidence that should not travel through the rest of the pipeline.

If the real problem is broader than one artifact handoff, our Atlassian integrations guide covers how to design Jira, source control, CI/CD, and deployment integrations without creating a sync mess. Avaratak's DevOps consulting work focuses on those delivery-system boundaries rather than adding another tool by reflex.

Why This Matters More Than the Release Notes Suggest

A few patterns suddenly become much cleaner.

Build once, test in parallel children. Your parent compiles the artifact. Three child pipelines, running in parallel, each pull that exact artifact down and run a different test suite — unit, integration, end-to-end — against it. No rebuild. No cache invalidation puzzle. No wasted compute. Build minutes go down. Confidence in the artifact-under-test goes up.

For a separate AI-assisted test workflow, our Bitbucket agentic pipelines guide covers Claude-based investigation and human review.

Let children produce, parents publish. The mirror version. Child pipelines generate coverage reports, security scans, or dependency audits. The parent gathers them up, attaches them to the merge request, and decides whether to proceed with deploy. The child stays focused on producing one clean output. The parent stays focused on coordinating. Nobody is reaching across pipeline boundaries through external storage just to pass a JSON file.

Reusable child pipelines that take real inputs and produce real outputs. This is the one I'm most excited about. With variables flowing in and artifacts flowing both directions, a child pipeline starts to look exactly like a function call — typed inputs, typed outputs, encapsulated logic. Teams can finally build a library of reusable child pipelines (a "scan this image" pipeline, a "lint this language" pipeline, a "deploy to this environment" pipeline) that get composed across dozens of projects without each project reinventing the wiring.

That last pattern is the one that quietly changes how mature engineering organizations build CI/CD. It's the difference between every team writing their own pipeline from scratch and every team consuming a curated library of vetted, secure, observable pipeline modules. The blast radius of "we updated the security scan" goes from "every team please update your YAML" to "we updated the central pipeline; you'll get the new behavior on your next run."

The Avaratak Take

A few honest words from the trusted-advisor seat.

Audit your S3 workarounds. If your CI/CD has cloud storage in the loop only because parent/child pipelines couldn't share files, that's a refactor worth scheduling. Removing it cuts complexity, removes a whole class of credential management problem, and usually shaves real money off your build infrastructure bill.

Treat child pipelines like reusable modules. Now that they accept variables in and artifacts out, design them with that contract in mind. Name your inputs. Name your outputs. Document the contract in a README in the same repo. The teams that lean into this end up with internal pipeline libraries that look more like SDKs than scripts.

Pair this with the new artifact types. Atlassian shipped shared and scoped artifact types alongside selective download last fall. Use shared for the artifacts you're passing between parent and child. Use scoped for the per-step logs and screenshots you don't need to ship downstream. The combination keeps your pipeline storage tidy and your steps fast.

Don't over-engineer day one. The first project we ever migrated to parent/child pipelines went too far, too fast, and ended up with a tree of pipelines harder to read than the monolith we'd replaced. The right move is to extract one or two clearly reusable patterns first, validate them on real workloads, and let the abstraction earn its way deeper into your CI/CD architecture.

Worth Saying Out Loud

There's a particular kind of joy that comes from watching a tool retire one of your workarounds. Every team has a list of duct-tape solutions they've stopped noticing — bits of clever scaffolding that exist only because the platform underneath wasn't quite finished. When the platform catches up and the workaround can be deleted, the team gets back not just the maintenance overhead but a small piece of clarity. The mental model shrinks. The architecture gets honest.

That's what this update is. Not a flashy feature with a launch event. A quiet, useful closing of a gap that build engineers have been working around for a while. The kind of release that pays compounding dividends inside teams that actually use Bitbucket Pipelines as a serious part of their delivery infrastructure.

If you're running parent/child pipelines today and your S3 bucket has a "pipeline-handoffs" folder, this is exactly the conversation we love at Avaratak Consulting. Stop by avaratak.com and bring your messiest pipeline. We'll bring the refactor plan. Together we'll figure out which of your workarounds can finally retire to the part of the YAML where they belong — the git history.

Related reading

• Cursor in Jira: From Work Item to Code
• Jira and Confluence Automation: A Guide