Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Query on Native Multi-Branch Deployment Support in Bamboo Specs

suriya
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 26, 2026

Hi Team,

We are currently using Bamboo 9.6.5 and are looking for a native way to handle multiple branch deployments using Bamboo Specs, similar to how GitHub Actions or other CI/CD tools allow branch-specific workflows.

Our requirement is to define branch-specific deployment logic within the Specs, so that when a particular branch is built, only the corresponding deployment process is executed.

At the moment, we have implemented this using a Script Task with multiple if/else conditions to check the branch name and execute the appropriate deployment steps. While this works, it becomes difficult to maintain as the number of branches increases.

Could you please confirm the following?

  1. Is there any native Bamboo Specs feature in Bamboo 9.6.5 that supports branch-specific deployment logic without relying on scripting?
  2. Can Bamboo Specs define different tasks or deployment flows based on the branch, similar to GitHub Actions branch filters?
  3. If not, what is the recommended or best-practice approach for managing multiple branch deployments in Bamboo Specs?

Any guidance or documentation would be appreciated.

Thank you,
Suriya

1 answer

1 vote
Gabriela - LeanZero
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
July 27, 2026

Hi @suriya, Bamboo puts the branch filter on the deployment environment's trigger. AfterSuccessfulBuildPlanTrigger takes triggerByBranch(String planBranchName), "Configure trigger to start deployment when plan branch is updated", so each environment gets its own trigger and only the matching one fires when that plan branch builds:

new Environment("Deploy QA")
    .triggers(new AfterSuccessfulBuildPlanTrigger().triggerByBranch("release/qa"))

One literal branch name per trigger. No wildcards. In the 9.6.5 API the only branch options on it are triggerByBranch and triggerByMasterBranch, and the one trigger condition shipped in that package is PlansGreenTriggerCondition, so there's nothing pattern-based like GitHub's branch filters. Since Specs is Java you can loop over your branch list and generate an environment plus trigger for each, which is the maintainable version of the if/else you're running now.

suriya
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 27, 2026

Thanks! Could you share a sample pipeline/spec showing how you've configured this?

Also, I'm not using Java Specs—I'm using YAML. Is there an equivalent way to configure branch-specific deployment triggers in YAML, or is this only supported through Java Specs?

 

Gabriela - LeanZero
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
July 27, 2026

YAML Specs has it too. The branch goes on the environment's build-success trigger:

---
version: 2
deployment:
  name: Deploy Rocket
  source-plan: MARS-ROCKET

release-naming:
  next-version-name: 0.${bamboo.buildNumber}

environments:
  - QA
  - Staging

QA:
  triggers:
    - build-success:
        branch: release/qa
  tasks:
    - clean
    - artifact-download:
        destination: /
    - script:
        - ./deploy.sh qa

Staging:
  triggers:
    - build-success:
        branch: release/staging
  tasks:
    - clean
    - artifact-download:
        destination: /
    - script:
        - ./deploy.sh staging

That is the deployment skeleton straight out of the 9.6 YAML Specs doc with the triggers dropped in, so scan it once before you build the rest on top of it.

The value under branch is the Bamboo plan branch name, not the branch name in your repo. That is what trips most people up, per Alexey from Atlassian on the same question. The plan branch also has to exist by the time the spec scan runs, otherwise the scan fails with "After successful build plan: Can't find triggering branch" (KB).

No loop in YAML though, so it stays one environment block per branch.

Like Steffen Opel _Utoolity_ likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events