As part of an initiative to increase the flexibility and power of child pipelines, we are happy to announce that Bitbucket Pipelines will now allow you to share artifacts between parent and child pipelines.

This feature extends the use-cases for child pipelines, allowing a greater degree of coordination between parent and child and the use of child-pipelines as modular pieces of processing for larger operations with artifacts.

Here’s how it works.

Configuring your bitbucket-pipelines.yml file

In your pipeline steps, you now have the option to specify an artifacts section with a list of upload and/or download artifact names. If an artifact is listed amongst the upload artifacts, the last version uploaded by its parent will be shared into the child pipeline, available for download in all of its steps. If an artifact is listed amongst the download artifacts, the last version uploaded by the child will be shared into the parent pipeline, available for download in all of its steps subsequent to the child pipeline step.

Check out the example below:

pipelines:
  custom:
    share-artifact-child-pipeline:
      - step:
          name: '2a. Update Artifact'
          script:
            - echo "Child pipeline update!" >> bottle.log
          artifacts:
            - bottle.log
    share-artifact-parent-pipeline:
      - step:
          name: '1. Create Artifact'
          script:
            - echo "Artifact created in parent pipeline." > bottle.log
          artifacts:
            - bottle.log
      - step:
          name: '2. Call Child Pipeline'
          type: pipeline
          custom: share-artifact-child-pipeline
          artifacts:
            upload: 
              - bottle.log
            download:
              - bottle.log
      - step:
          name: '3. Read Artifact'
          script:
            - cat bottle.log

If we were to run share-artifact-parent-pipeline, the steps would execute as follows:

  1. Create Artifact – We create an artifact (in this case a log file) in the parent pipeline, with some initial text.
  2. Call Child Pipeline – We call the child pipeline, both uploading and downloading the log file.
    1. Update Artifact – Because the artifact has been uploaded, the step inside the child pipeline can use the input artifact. It then appends some additional text and re-uploads it.
  3. Read Artifact – Because the artifact has been downloaded, the step after the child pipeline can use the output artifact. With both the initial state from the parent and the update from the child we would expect the log file to read:
Artifact created in parent.
Child pipeline update!

Further Info

To learn more about how to set up config sharing, please refer to the support documentation.