Parallel Test Execution in Bamboo Using Multiple Jobs and Agent Pools

Problem

Teams need to run large test suites faster while keeping test data isolated per run and avoiding promotion of incomplete artifacts. Bamboo does not provide a native matrix feature that spawns dynamic rows from a single job definition. As of 2026-10-14, the supported way to run work in parallel is multiple jobs within a stage, each scheduled to a distinct agent.

Key Requirements

• Parallel execution of test suites on separate agents.
• Per-job isolation of environment data such as database URLs.
• Deterministic artifact handling between stages.
• Environment boundaries enforced by agent pools.
• Clear visibility into which agent ran which job.

Smallest Suitable Design

The minimal design is one Bamboo plan with one stage containing N jobs, one per test variant. Each job is assigned to a dedicated agent pool via agent requirements and defines its own variables.

With Bamboo Specs the structure is conceptually:

plan:
  stages:
    - test:
        jobs:
          - test-db1
          - test-db2
          - test-db3
          - test-db4

This is illustrative only and not tested. Each job references the same test task but overrides variables such as DB_URL. Agent requirements restrict scheduling to a pool named TestPool. Agent requirements are capability name=value pairs configured on agents and referenced in the job.

Artifacts are published from each job to the plan artifact repository. Promotion to a downstream stage is done via explicit job dependencies, not automatic aggregation. The downstream job should depend on all test jobs and declare which artifacts it consumes.

Trust and Data Boundaries

Agent pools provide a hard boundary. Agents are members of a pool in Bamboo administration and jobs can be restricted to that pool with requirements. This prevents test jobs from running on production agents.

Environment variables are inherited from the plan but can be overridden per job. Secrets should be stored in Bamboo variables with restricted visibility and referenced in tasks without echoing them to logs. Do not print secrets in build scripts.

Artifact repositories are per plan. Access control is managed via Bamboo project permissions. Only jobs that succeed can publish artifacts that downstream jobs will consume if the dependency is configured to require success.

Operational Checks

1. After a build, open Plan → Builds and inspect each job’s execution summary to confirm the agent name and pool.
2. Check Plan → Artifacts to confirm artifact entries exist for the expected jobs.
3. In Bamboo administration, review Agents and Pools to verify that agents in TestPool have the expected capabilities and are online.
4. Review build logs for redacted placeholders when variables are used, indicating secrets are not printed in clear text.

These checks are manual UI checks. Automated verification would require the Bamboo REST API, whose exact paths and payloads should be confirmed against your installed version.

Failure Modes

• Agent loss during a job. Bamboo will mark the job as failed and will not retry unless configured. Orphaned processes can remain on the agent. Agent watchdog settings control process termination and should be reviewed per installation.
• Non-deterministic artifact visibility. Because artifacts from parallel jobs are independent, downstream jobs must explicitly declare dependencies on all upstream jobs. Otherwise a downstream job may start before all artifacts are available.
• Secret leakage. Printing variables to console can expose credentials. Use Bamboo’s variable masking and avoid logging variable values.
• Pool misconfiguration. If agent requirements are too broad, a job may schedule on an unintended agent. Verify requirements in the job configuration and in the agent capabilities.

Bamboo does not provide built-in fail-fast across parallel jobs in a stage. Stopping the whole plan when one job fails requires additional orchestration, such as making downstream stages depend on all jobs and monitoring manually. This behavior should be verified in your version.

When to Re-evaluate the Design

• Test variants grow beyond a manageable number of static jobs. Static job duplication becomes cumbersome. Consider generating Bamboo Specs from a template or moving to a different CI system that supports dynamic matrices.
• Different operating systems or software stacks are required. Use capability-based agent requirements to route jobs to appropriate agents, or split into separate plans.
• Artifact aggregation needs metadata such as combined test reports. Add an explicit aggregation job that depends on all test jobs and runs after they complete.

Limitations: This design uses static jobs, not a dynamic matrix. It requires manual maintenance as test variants change. Behavior of artifact dependencies, agent scheduling, and variable masking can vary by Bamboo version. Verify all configuration in a non-production environment before use.