Configuring artifact dependencies between Atlassian Bamboo plans

Problem: Downstream Bamboo jobs can't find upstream build outputs

In Atlassian Bamboo, a common CI pattern requires a downstream plan to consume build outputs from an upstream plan without triggering a full rebuild. Without a configured artifact dependency, the consumer either stalls waiting for files that never arrive or rebuilds the upstream work unnecessarily. This article explains how to declare an artifact dependency between plans, select the correct producer build result, and verify that the files land in the consumer's working directory as expected.

Desired outcome

Configure a consumer plan so that, after a successful producer build, the expected artifacts appear in its working directory at build time, allowing subsequent deployment or test steps to run against the fresh output without re-executing the upstream job.

Necessary prerequisites

• Two Bamboo plans on the same instance; artifact sharing across instances requires an external repository such as Nexus or Artifactory.
• Artifact name and location defined on the producer plan's Artifacts tab.
• User rights to modify plan configuration on both the producer and consumer plans.
• Remote agents must have read access to Bamboo's local artifact storage directory; network latency or firewalls can block large file transfers.

Focused procedure

1. Define the artifact on the producer plan. Open the producer plan, navigate to the Artifacts tab, click Add artifact, and specify the Artifact name (e.g., myapp.war) and File pattern (e.g., target/myapp.war). This tells Bamboo which files to publish after a successful build.
2. Add the artifact dependency on the consumer plan. In the consumer plan's configuration, go to the Artifact dependencies section, click Add dependency, select the producer plan, and choose a Build result rule. The options are:
   • Required, follow triggering relationship — the consumer waits for the producer build that triggered this run.
   • Required, latest successful build — the consumer uses the most recent successful producer build, regardless of trigger.
   • Optional — the consumer proceeds even if no matching producer build exists.
3. Save and run the consumer build. Trigger the consumer plan manually or via a trigger. Bamboo will resolve the dependency, download the artifact files to the consumer's working directory, and log the transfer.

Expected checks

• After the producer build, inspect the build result's Artifacts tab: the listed files should match the defined pattern and size.
• In the consumer build log, look for entries such as Downloading artifact myapp.war from plan X. The absence of this entry usually means the dependency rule did not match any producer result.
• Check the consumer's working directory (on the agent) for the artifact file. Compare its checksum or size against the producer's published artifact to confirm integrity.
• Verify the consumer plan's Artifact dependencies settings: which producer build is required and what happens when no matching result exists.

Verification via Bamboo REST API

To programmatically confirm the dependency resolution, use Bamboo's REST API endpoint GET /rest/bamboo/plan/1.0/plan with the consumer plan key. Run the command on a machine with network access to the Bamboo instance and valid API credentials (an API token or session cookie with bamboo.admin or bamboo.plan scope). Replace <base-url>, <plan-key>, and <auth-token> with your values:

curl -s -u 'ADMIN:API-TOKEN' 'BASEURL/rest/bamboo/plan/1.0/planPLANKEY' | jq '.plan.artifactDependencies'

Expected check: The JSON response should list a dependency entry referencing the producer plan key and the selected build result rule (e.g., latestSuccessful). If the entry is empty or shows noMatchingBuild, the dependency did not resolve.

Relevant risk: API responses vary by Bamboo version; the endpoint and field names changed between 7.x, 8.x, and Data Center releases. Always cross-check the output against your deployed version's documentation.

Recovery and limitations

Artifact expiry and global cleanup can remove old build results. If a consumer references an expired or deleted producer build, the dependency resolves to nothing and the build may fail or proceed without the files. Recovery is to re-run the producer plan or extend the plan's Artifact expiry settings and Bamboo's global cleanup schedule. Plan branches add another layer: a feature-branch consumer may resolve artifacts from the corresponding producer branch rather than the default branch, so confirm branch matching rules if your pipeline uses feature branches. Large or frequently changing binaries should be published to a dedicated package repository rather than Bamboo's artifact store, as they bloat the store and slow builds. Finally, deleting or renaming the producer plan or artifact breaks existing dependencies; keep artifact names stable or update consumer dependencies in lockstep.