Bamboo is software by Atlassian that will build your software and do stuff https://www.atlassian.com/software/bamboo You might also know Jira, Confluence, Crowd & Stash. Their PR machine is excellent (Like that time when they hijacked 10 years GIT. They made a beautiful congratulatory page & article that had half my twitter feed think Atlassian invented git.  They released Stash in 2012 that incorporates git amongst others. Git was creaded in 2005.)

Installing Atlassian software leads to frustrations, about the most stoopid shit. Mostly lack of full information. Like default port numbers, etc. So in my horrible search, I’ll write some of the shit I found out here, for those who care. This might grow after posting as the frustrations continue.

I don’t feel like I’m pushing the envelope either, we just need our software installs to be fully automated in Ansible, repeatable without human interaction and flexible. Something we achieve for our own software, for a bunch of other middleware, but that fails horribly for the Atlassian stack.

Bamboo Network Ports?

This depends on your config, but by default, you’ll need to open port 8085 for http access and port 54663 for your remote agents.

 

Elastic Bamboo EC2 IAM policy

In short, there is no official EC2 IAM policy.

Atlassian wants you to just give Bamboo full access to your account. You don’t want that.  Horror stories about what can go wrong, like auto terminating unrelated machines in this question “What permissions does the bamboo IAM user need for Elastic Bamboo?” You don’t want to give Bamboo rights to any account running anything serious. But if you need security, you’ll need it in the same account for VPC reasons, etc. A request for such a policy (this is less that 50 short lines of text) has been filed in July 2012 as BAM-11932 and there has been no answer to date except that they will not provide a IAM security policy for this big  bamboo feature.

You can at least restrict the accunt to the services it needs, as to not have full priviliged accounts floating around, but ultimately, this does not solve any real problem, where your Bamboo instance might shut down all your production machines.

{
 "Statement": [
 {
 "Action": "ec2:*",
 "Effect": "Allow",
 "Resource": "*"
 },
 {
 "Effect": "Allow",
 "Action": "elasticloadbalancing:*",
 "Resource": "*"
 },
 {
 "Effect": "Allow",
 "Action": "cloudwatch:*",
 "Resource": "*"
 },
 {
 "Effect": "Allow",
 "Action": "autoscaling:*",
 "Resource": "*"
 }
 ]
}

I am working on a policy that would allow Bamboo to only control his own buildnodes, but so far I have no code to post here.

Bamboo behind a Proxy

The documentation here is not that horrible. It’s all there, just read it very carefully & twice. Also, there are multiple pages for this.  The very official looking “Integrating Bamboo with Apache HTTP server” in the documentation; and the actually much more helpful “How to set up Bamboo behind proxy (Apache)”

These documents however do not touch on the considerations for running remote agents with a proxied setup. (see further the remote agents point later)

 

Remote agents

The documentation about remote agents makes them seem MAGICAL. Just run the provided line & shit ‘ll work. This might be the case when you just dump all your machines in the network, connect directly to the Bamboo machine, etc. If you need to run this on internet with (god forbid) security, VPCs and a reverse proxy, this won’t do.

The main resource here for starting the configuration is “Troubleshooting Remote Agents” and you’ll want to look at what addresses to use for the bamboo.jms.broker.client.uri & bamboo.jms.broker.uri that you set in the general settings page

The URL provided for starting the remote agent will probably contain the URL you put in the config as Base URL. If you’re proxying, this will not work and you will need to replace this with the actual IP of your bamboo server.  This is because the broker communication is over a different port, you might also proxy or tunnel this port from your Proxy to solve this.

java -jar atlassian-bamboo-agent-installer-5.8.1.jar http://<ip>/agentServer/

Hipchat.

So, like .. (I’m in simple mode, because my mind is still blown. I’m not surprised, mind you, just a blown mind.) We use Atlassian Hipchat & the previous build tool uses that extensively. As one would expect 🙂 So when moving to Atlassian Bamboo, I’d expected near automagic Atlassian Hipchat connecting, a bit like what they try with Jira & Confluence, but simpler, because it’s only chat. ….. No.

Note that Bamboo does not yet support using HipChat as a global IM server. HipChat can only be used in the plan notifications area as shown here
source: Integrating Bamboo with HipChat

There is an IM server pane in the setup. Ignore that, Hipchat is not meant to go there. You can try, but I didn’t get it to decently work, even though “succesfully” sending messages into the aether.  Trying to get this working none the less meant making a paying user on Hipchat instead of an API key, etc.  Spare yourself the time.

The ONLY official way today to connect Hipchat to Bamboo is to configure it per build plan in the notifications pane. The “add notification” button has a Hipchat option.. never mind the “no IM server” message. There you can add an API key.
Getting this to work on a Hipchat server you run yourself is .. well, creatively solved by editing /etc/hosts (you see where this is going, I’m really trying to stay positive though)
You can NOT hoewever add this server wide & the only real option is to provide an admin level api key to everyone who needs this in their build plans. (Before you ask, I don’t want to let users create those api keys with their accounts, I don’t need half the build plan notifications to stop working after we delete his account for any reason) The Hipchat API at admin level alows full access to everything, including creating and deleting users, rooms, etc. Licences are per user, so you’re essentially putting user details with access to actions that generate extra costs out in your user base. Just so your hipchat users can read that there’s a build ready. (I wish I was making this up)

The only hope for a better solution lies in a user comment by “asdf asdf” on the Integration page. The sad truth is that they used a third party plugin to connect Atlassian Bamboo with Atlassian Hipchat. I am loathe to go find out how much it costs. (I’m not adverse to spending money for good reasons but this would be absurd)

We are using the 3rd party plugin “HipChat rooms” as a workaround.

It has a global configuration to specify hosted HipChat host and as a bonus room name is easily selected from a list that is presented to the user.

The plugin when configured is available as “Hipchat Rooms”, but the plugin itself is called “HipChat plugin for Bamboo“. Made by Go2Group, Vendor supported and Free. (They must be saints.) And more importantly, It Just Works. And it keeps my credentials safe. Like any “Connect to a chat server” thing should, this day and age.

Consider & fix as you prefer, but we ended up installing a third party plugin to get 2 Atlassian products to work together. (Try reading that last bit out loud.)

Some links of relevance and hope, yet ultimately only sadness & frustration.

• Hipchat XMPP/Jabber support details
• Your XMPP account details are in https://hipchat.com/account/xmpp (Spoiler, user name etc are otherwise hidden ID numbers)
• Integrating Bamboo with Hipchat
• hipchat.com/addons/info/bamboo
• The Solution: HipChat plugin for Bamboo

MORE questions!

The questions keep coming & most of these aren’t rocket science, it’s just that for a commercial product, the solutions aren’t very professional and the search to find them is often simply horrible. And sometimes, the functionality is Just Not There.

Questions I’ve figured out & will update on

Where is the database config etc?
Can I automatically install Bamboo
What about the bamboo init script & how good is it?

 Questions I have still to figure out

Can the remote buildnodes detect their Agent-specific capabilities, like different java versions?
How do I provide the buildnode with a list of his Agent-specific capabilities, so that it can tell the server?

 

Provided for the courtesy of anyone who needs this info.

Because I don’t feel I’m asking anything spectacular here & the information is simply lacking.  So in the hopes of sparing if only one person the frustration.

I was recently asked to speak at the fresh local Atlassian User Group meeting, but honestly, I don’t feel my current experiences make me a good spokesperson, unless the point is to wallow in collective disgust at how horrible some things work.

The fact that I was prompted to make a page like this honestly says it all.