Popular Articles

The XebiaLabs DevOps Platform provides visibility and synchronizes data across the CI/CD pipeline by connecting issue tracking and ITSM ticketing tools, so that user stories and change tickets are always up to date.

Subscribe for more!

I discovered that XL Release does not have built-in support to integrate with the Bamboo build tool as it does for Jenkins. But I also discovered that XL Release’s extensibility makes it easy to configure a type definition and a script to enable an interface with Bamboo.

Let’s look at the support for Jenkins. XL Release provides a task definition:

and an entry under the configuration tab:

With these we can define one or more Jenkins servers and use them to execute the build jobs defined on them. Nice.

Bamboo doesn’t have such out-of-the-box support, so let’s take a look at how we could configure the objects we need. Since Bamboo has a REST API, we can extend the HttpConnection object to provide us a Bamboo Server object by defining a type in xl-release-server/ext/synthetic.xml:

<type type="bamboo.Server" extends="configuration.HttpConnection" />

Now we need a task to call out to the API; let’s extend the PythonScript object for this so we can take advantage of Python tremendous versatility. The script will actually run under Jython, so we can utilize Java classes too if needed. Our input will be the project-plan key to identify the Bamboo plan, and let’s code a few output fields to return some information about the build after it completes.

Our next task is to write the Python script to call out to Bamboo. The namespace of the type, “bamboo” in this case, determines the script directory, and the type name determines the script name. So our script will be called RunPlan.py and will live in xl-release-server/ext/bamboo.

The script starts with some typical Python imports. We’ll use com.xhaus.jyson.JysonCodec for json since that’s included in the XL Release libraries. Next we set some variables for contentType and headers for all of our HTTP calls, and define some boolean and text fields from the build result.

Finally the main body of the code make a post request to Bamboo’s url using the built-in HttpRequest object. We supply the url, content type and headers. We could have added authentication here to override what’s defined on the Bamboo Server object, but let’s leave that for later. An empty set of curly braces is required for the JSON content body.

Then we use the JSON library module to parse two items out of the results: the build number and the build result key.

We store the latter in the variable brkey to keep it handy to pass to our helper methods. A simple while loop polls for a finished result every five seconds. That interval would be better as a configurable value; this is something else we’ll save for later.

When the loop ends, we query the job’s results (note the change in the query string from “queue” to “result”), print some messages and set the two state output variables so XL Release can use them to control future actions. See the xlr-bamboo-plugin repo for future updates to the code.

Dave Roberts is a Senior Technical Consultant for XebiaLabs. He has worked on both sides of DevOps, as a web software engineer and as a WAS/DB2 administrator.

The Reality of Software Releases

Many organizations model software delivery as if the features that are initially planned for a release are always the features that are actually delivered to production when the release is done. But the reality of software releases is more complicated than that, because it’s hard to predict the delivery of planned features. The XebiaLabs DevOps Platform can help you deal with the reality of software releases. See for yourself!

Start Your Trial

The XebiaLabs DevOps Platform provides the intelligence, automation, and control that technical and business teams need.