Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Bamboo Specs - Choice of language (YAML/DSL/Java)

SG Atlassian Team May 02, 2017

Discussion carried over from --


Hello, all!

Following the Bamboo Specs announcement, I created a Groovy DSL on top of the library provided by Atlassian. It is available on GitHub here:

The DSL simplifies the definition of specs, by providing the power of the full Bamboo Specs API, but leveraging the much more readable and scriptable platform of Groovy. Take a look at the README and the examples directory for usage samples. I'd love to hear if you have any questions or improvement suggestions. Just open an issue on the GitHub repo.

Thank you!


Hi Brian,

leaving aside that the whole Bamboo Specs is a shoot in the foot as a simple .yml file should had been enough, I think you started a good initiative with this DSL that I discovered today. The only way I was going to use Bamboo Specs anyway was in a Groovy script cause it is the only way to have everything in one single script file, but your DSL makes things better. I guess the only thing missing would be IDE autocompletion. I'll see if I can help with that.


If I'm understanding this right, we want to be able to configure build plans via YAML. Bitbucket Cloud does this with Pipelines. I feel the same ability should be carried over to Bamboo.

After using tools like Travis and Pipelines, I very much dislike all the work necessary to configure Bamboo. It should be as simple as having a .bamboo.yml file in the repo, just like with Pipelines.

I don't want to write Java or Groovy or anything else to configure my builds. I don't want to go through a less-than-simplistic web GUI, either. It's annoying, compared to alternative products out there. Not all of our team members know Java, so they can't take advantage of Specs easily.

It is incredible how a simple request (BAM-15087) could go that wrong…

Bamboo build plans are basically data. A multi level structure
(plan/stages/jobs/tasks), but still not code – really no control structures and such. It should be possible to define most build plans with simple YAML file. Basic includes could help with more complex configuration.

Code could be useful for adding extra logic into the build plans, but this still seems impossible withing Bamboo. And I would rather see some scripting language here instead of Java.

All that Java boilerplate is completely unnecessary. Yeah,  it might be simple for a Java developer and IDE would auto-complete most of the stuff, but for any simpler solution that would not be necessary. Requiring Jace IDE where a simple text editor would be enough is a bit of overkill.

Bamboo already reads VCS – it should be trivial to make it locate the configuration there. The Maven requirement and the deploy step from outside of Bamboo seems insane. Instead of a build configuration file we got a whole new software project to add to any project we want to build.

I will probably still try to use this, as having build configuration in VCS is better than not having it there, but it is quite disappointing such a reasonable feature request was broken so much.

I edited a yaml file this morning to update an appveyor file changing the worker process. I did it on github with no other tools that a browser and it worked.

This java DSL is IMO a hot-mess that is just hostile to non-java dev's and pigeon-hole's bamboo as a java-only CI server and limits your market.

Abandoning the simple yaml approach in the prev version was a poor decision and I hope the bamboo team come to their senses and implement proper declarative config via yaml or similar ASAP and join the rest of the CI servers, instead of thinking being the odd-one out is actually a good thing in this particular use-case, it really isn't! 

Like # people like this

I agree. Atlassian lists some 'advantages' of using java for config, but we find exactly 0 of them compelling. By their own admission, YAML gets the job done, so why aren't we able to use it?


That pretty much sums it up.  When the community is creating DSL's 5 minutes after you release your "DSL" that's probably a good indication that we've missed the mark.  I'd seen it advertised but hadn't had a chance to dig in to the features, but just assumed it'd be something like Pipelines or what other tools do.  Just had our Ops guys upgrade to 6.x and rolled up my sleeves, opened up the tutorial, and I'm kind of just sitting here wondering what happened 

Not sure if should laugh or cry.

Anyone has a good "Maven (behind the firewall) for dummies" that I can borrow?

So, first things first:  This isn't what was asked for in  

That card, and most of the other cards relating to configuration-as-code, were meant to address the ability to configure CI through a configuration file.  This is a functionality available to both external (Travis et al.) and internal (BBP) competitors, and the lack of it in Bamboo has been a sore topic for a long time.  The most common use case to derive from this would be to allow a development team to control the structure of their build process by providing a plan creation option that would point to a repository, read the .bamboo.yml out of it, and generate configuration accordingly.  When the configuration file changed, the next build triggered would propagate the plan changes (if possible) and then execute them.  This would give developers the ability to develop and hack with their own CI (per branch, even, if necessary) and let administrators deal with higher-level management issues.

Bamboo Specs appears to address a different, highly specific use case for administrators, which is to treat the instance-wide Bamboo configuration as if it were a Chef node.  It provides a programmatic interface for writing out the configurations of one or more plans--which is *great*, don't get me wrong--but it has serious issues for actual developers or DevOps:

  • No ability for non-admins (i.e., teams) to push configuration safely;
  • No ability to have per-branch configuration without using the script-task-based hacks currently in use;
  • No default or dynamic loading of configuration from a standard location;
  • No direct support for YAML configuration;
  • No direct support for languages other than Java.

As an administrator who *does* have to deal with thousands of plans, I *do* have potential uses for Bamboo Specs.  In point of fact, I find the idea of generating (and maintaining) static sets of plans pretty desirable for managing environment deployments.  (We don't use deployment projects for this purpose because of their inflexibility.)  Having said that, when it comes to managing actual CI plans, Specs pales in comparison to hitting the Create Plan button, pointing at a repository, and never having to think about that plan again.  In this situation, I don't have to deal with managing the thousands of plans.  I would point at the YAML spec, provide best practices, and monitor the health of the instance and agents rather than end up being the gatekeeper for every pull request coming down the line from my customers.

As it is now, the current implementation provides me no reason to deviate from our current approach to decentralized administration (define 'standard' tasks for any build, call out to in-repository scripts which implement them).  I might use Specs to generate that plain template, but I already have it, so I can just clone it...why bother doing more?

Super disapointed with the feature release.

A simple yaml file is all thats required. Now considering moving away from bamboo instead of upgrading. 

Is anybody using this in production yet?  Have any experiences to share?  Are you keeping one massive project in git, or are you keeping some sort of smaller piece of code in every application repo?

I am extremely confused by this product...I hope I am missing something obvious.  It's marketed like it's 'configuration as code', but appears to just be a java project template and some APIs exposed?  Should I really need almost 30 import statements and unit tests in order to do this?  My team does not include anyone who's been a java dev in a past life, and while it won't be hard for us to learn, it WILL be hard for us to start that process with a project template this large and complex.  So far I am seeing a very slim possibility of success here. 

Some of us have made attempts to use specs, but are mostly disappointed. The biggest problem is that specs just introduces another piece of code that needs testing for every project... It's been more counter-productive than productive compared to manually configuring plans. . .

How many plans do you have?  My team has nearly 100 and maybe adding as many as 50 in the future.  We are weighing the risk of using a brand new and very complicated feature vs the risk of just totally tossing Bamboo and using TeamCity/Jenkins/TravisCI, etc.

Like Mike Eldridge likes this

Thanks everyone for the feedback!

In Bamboo 6.2 we delivered the possibility to define a plan in YAML format. It follows the format used by Bitbucket Pipelines. 

Please have a look at for more details.

This is a 'technical preview' and we strongly encourage you to send us feedback, so that we could shape format of this YAML according to your needs.

Amazing thank you for listening. This is definitely the right direction for what we would like to see and use. We will be upgrading to take advantage. 

It's a start.  However, without branch support and functionality which is more or less equivalent to that of the Java spec, this is only usable for the most simple types of plans.  It's vastly more flexible (at this moment) to have a Bamboo spec that generates a skeleton that calls scripts within the repository.

Like Mike Eldridge likes this

Agree with Jerry

As I have mentioned in another thread, what I am really looking for (and what other CI tools already have) is a mechanism to keep plans in revision control (preferably along with the code being built).   Without this we have to constantly be worried accidentally breaking things or how to support legacy code.

It doesn't look like this new YAML feature gets us any closer to what we need since there is no way to export an existing plan to it and it can't even support the full complexity of Bamboo plans. 

Another feature available in 6.2 is Repository Stored Specs, which does exactly that.

Repository Stored Specs don't solve this. You can only have 1 configuration for many branches. We need many configurations for many branches. Each branch should be able to have its own configuration. In VCS. Evaluated on a per-build basis.

Like Mike Eldridge likes this

My work around for this has been to have the script section of the build execute a shell script. This shell script can then differ between branches offering us semi-divergent branches Semi as it does mean that branches cannot differ in anything that has to be done via the yaml file).


Log in or Sign up to comment
Community showcase
Published in Bamboo

Bamboo Data Center on Kubernetes

Hi, If you are running self-managed environments and looking to adopt modern infrastructure, Bamboo Data Center can now be deployed in a Kubernetes cluster. By leveraging Kubernetes, you can easily...

965 views 3 8
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you