Build Once in Bamboo: Share One Artifact Across Plan Jobs

The problem: three jobs, three compilations

A common Bamboo plan for a Java service has a build job, a test job, and a deploy job, and each one runs something like mvn -B package. The same source tree is compiled three times, the plan takes longer than it should, and there is a quieter risk: each job may end up acting on a slightly different binary, so the artifact you tested is not guaranteed to be the artifact you deploy.

The useful decision is to compile once. In a Bamboo plan, define the resulting file as an artifact on the producer job, mark it as shared with the other jobs in that plan, and let the test and deploy jobs consume that one file instead of rebuilding it.

What a shared artifact actually is

An artifact in Bamboo is a labeled set of files produced by a job, for example a label such as service-jar pointing at target/service.jar. When you enable the option that makes a job's artifacts available to other jobs, downstream jobs in the same plan can read those files from the shared artifact location instead of regenerating them.

Scope matters: this sharing is within one plan. It is not a binary repository and does not by itself give you reuse across plans, branches, or release lines. Also, the exact field names, the shared directory path, and any related environment variables differ across Bamboo versions, so confirm them in your own instance's documentation and release notes rather than hard-coding assumptions.

Worked example: one producer, two consumers

Take a plan with three jobs:

1. Build job (producer): run mvn -B -DskipTests package, then define an artifact with label service-jar and path target/service.jar, and enable sharing to the other jobs in the plan.
2. Test job (consumer): do not compile. Run your smoke or integration checks against the shared service-jar artifact, resolving its location from the job log or the documented shared-artifact path for your version.
3. Deploy job (consumer): package or deploy the same shared target/service.jar file. Do not run mvn package again.

The expected check is simple: after the plan runs, open the test and deploy job logs and confirm they report the resolved shared artifact path and that the file exists before any script depends on it. Time the plan before and after the change to confirm the redundant compilation disappeared rather than merely moving cost into artifact transfer.

Trade-offs and failure modes

Sharing artifacts inside a plan solves the build-once problem, but it has real limits. Large artifacts add transfer and storage cost. If the producer job is skipped or fails, a downstream job may fail loudly, which is what you want, or it may fall back to stale output if the configuration is incomplete, which is not. Running a downstream job on its own can also behave differently depending on plan configuration and Bamboo version.

Keep two guardrails. First, keep exactly one producer job per plan so provenance stays obvious. Second, keep the artifact label and path stable, and make consumer scripts fail fast with a clear message when the expected file is absent instead of silently continuing.

Verify before you rely on it

Create a throwaway plan with two jobs, share one small known file from the first job, and confirm the second job can read it; inspect the second job's log for the resolved path. Then test the failure path by skipping or failing the producer job and confirm the consumer fails loudly rather than using stale output. Once that holds, add one shared artifact to a real plan and read the downstream job log before wiring deployment scripts to the path. For reuse across multiple plans or release lines, use a proper binary repository such as Nexus or Artifactory instead of plan-scoped sharing.