Bamboo scripted buildplans

Question

We are currently using bamboo to build and test our software. Now our build plans are just a bunch of task: execute this bat, execute that bat etc. Created with the Bamboo UI.

It happens that over months/years the build plan needs adjustments:

• Parallelize jobs
• Add extra jobs
• Change some tasks

But this will break when we try to build an older version of the software. Some scripts (called from bamboo task) are not-existing in older versions.

At my previous employer we used Jenkins pipelines where the content of the build and test was just a file present in the sources repo.

Now with bamboo it appears you can use Bamboo Specs. From I read you create specs file and when you run this, it which will create build plan. But I don't see a relation to cater for changing build plans over time (changing steps).

For example the Bamboo Specs of develop are used to build all Plan Branches (e.g. Pull Requests). So if you want to change the build in a PullRequest, you first need to merge this into develop, the Bamboo Spec of develop updates the Build Plan. Not possible to test this before merging.

Question: How can you make scripted buildplans in Bamboo, where every branch of develop can a have possible other way of building?

We have it now setup as:

• Buildplan 'Product A': plan branches: develop, release_x, release, y
• Buildplan 'Product A PullRequest': plan branches: feature/*

Answer 1

Edit: supported in 7.0: https://confluence.atlassian.com/bamboo/enhanced-plan-branch-configuration-996709304.html

Old answer:

I found Atlassian documentation: https://jira.atlassian.com/browse/BAM-19620. They call it 'divergent plan branches'. No support, there is a feature request.

As of 15-4-2019:

Atlassian Update – [11 April 2019] Hi everyone,

Thank you for your votes and thoughts on this issue.

We fully understand that many of you are dependent on this functionality.

After careful consideration, we've decided to prioritise [this feature] on Bamboo roadmap. We hope to start development after our current projects are completed.

Expect to hear an update on our progress within the next 6 months.

To learn more on how your suggestions are reviewed, see our updated workflow for server feature suggestions.

Kind regards,

Bamboo Team

Answer 2

Question: How can you make scripted build plans in Bamboo?

To make scripted build plans in Bamboo, you have to use bamboo specs. Since you are already familiar with Jenkins, bamboo specs work exactly like Jenkinsfile by automating your pipeline. The benefit of using this is that it lives in your source code and the changes you make to this file in your source code automatically changes your plan(pipeline) when bamboo build is triggered. This is how I script build plans in bamboo:

1. I add my bamboo.yml file under the root of my repo. But currently, I use git subtree and my bamboo specs live in there. But you don't have to do this. The below link provides you with a simple approach.
2. Link my repo to bamboo
3. Tell bamboo to scan for bamboo specs in the repo
4. Make commit and push

https://confluence.atlassian.com/bamboo/tutorial-bamboo-specs-yaml-stored-in-bitbucket-server-941616819.html

If I have to make changes to the plan in the future, I edit the bamboo specs file then commit and push.

Answer 3

I had the same problem and unfortunately had to go through an unpleasant choice

Backporting the build script

This is not necessarily feasible everywhere, but I managed to make it work somehow for my project.

The idea is: treat the build script as a C#/Java interface, or better as a contract.

As soon as your branches do not provide significant changes in building the software, e.g. your desktop app becomes a web app, or you switch from Ant to Gradle, you can handle this.

Assuming my application is always a web application to be released as a jar on JFrog Artifactory, I have identified the following steps that are common to all maintained versions:

• Use javac to build the jar of all modules
• Use gulp to build the Javascript resources
• Run JUnit from the repository
• Baptize the artifacts with a version number obtained with a tricky algorithm
• Push the artifacts to JFrog Artifactory

So the idea is that I had taken my Ant build script and mostly rewrote it in order to do the same tasks on different versions of the application. I started doing the changes from an older version, not maintained anymore, as an excercise. In fact, my official Git branches look like release/x.y.z where semver is x.y.z.k and newer bugfix-builds are built from the head of any x.y.z release.

So I took release/3.10.0 branch and rewrote Ant. I am currently testing with a manually created Bamboo plan

Stage: Compile

ant clean ivy-retrieve compile jar #builds the jar in a job
ant gulp-install gulp-prod zip #creates javascript resources

Stage: Test

ant run-junit

Manual Stage: Release

ant baptize ivy-release #tags the artifact using ${bamboo.jira.version} and pushes to JFrog Artifactory

What I am going to do with Yaml

Since the build script is the same, but specific tasks (e.g. Java compiler version) may change in different versions, I can create a very single Yaml script that rules them versions all.

I will then merge release/3.10.0 => release/3.10.1 => release/3.10.2 ... release/3.11.2 by merging the conflicts

Personal experience

Tonight I am struggling in making the JUnit tests work as I also chose to backport my testing framework to the older version of the project. I accept that a few tests will fail because older and non-maintained versions contain bugs. For me this is a way to prove that the system works.

Indeed, diverging branches are a great idea, but I am forced to use Bamboo 6 in my office