Moving things along: Continuous integration

Hi everyone,

Some of this data has been going around in an e-mail, but I figured that I’d let you all in on the progress.

We will be using an instance of Atlassian Bamboo to do continuous integration and to generate the distributables (including the nightlies). This Bamboo instance is available at http://bamboo.igniterealtime.org.

@akrherz was the first one to get one of the Openfire distribution generating targets to run - the RPM one! As from that moment, we have been generating installables again!

I have volunteered myself to be the lead admin of Bamboo, as I’ve got some experience with working in Bamboo. Currently, I have added a number of other build plans, as you can see in Bamboo.

In this discussion, I’d like to document my thoughts behind the organization of Bamboo - both to get your feedback as well as for future reference. So, here goes.

In principle, each of our projects (Openfire, Smack, etc) will get its Bamboo buildplans grouped in exactly one Bamboo project (using the same name). If you look now, you’ll already find and ‘Openfire’ and ‘Tinder’ Bamboo project.

Each project will have at one “continuous integration” buildplan. These buildplans:

  • do not generate artifacts
  • perform as much testing as possbile (eg, using unit tests)
  • report on as many bugs/issues as possbile (eg, using Clover)
  • are triggered by new code checkins to the source repository.

Each project will have one or more buildplans that generate distributables. These buildplans:

  • run once per day (nightly)
  • generate artifacts (the distributables)
  • add the nightlies to the website automatically (this has yet to be realized for the plans that have been created up until now)

Every buildplan uses the minimum version of the dependencies (‘builders’ in Bamboo) that should support the project. So, for example, Openfire will use a Java 1.5 SDK.

Authorization to change each build plan is set up as follows:

  • members of the bamboo-admin group are allowed to do anything
  • members of the -developers group are allowed to view, edit and run the build plan belonging to their project
  • other users (including anonymous users) will have read-only access.
  • we should make sure that permissions are not granted to individual users. Appropriate groups are in place, we use those instead. Please note that after creating a new buildplan, your user is added to the list of permissions automatically. You’ll have to remove that permission.

Oh, there’s the small matter of “I don’t know if the generated artifacts are actually installable on the target host.” Obviously, I didn’t try that. If you feel like trying, let us know what the results are!

So, for the Spark project i think you can add cstux to spark-developers group

Java 1.5? Not 1.6?

cstux already is in the spark-developers group. Note that the groups that are being used by Bamboo are the groups as defined in Crowd. Those in turn are based on the old JIRA groups. The new JIRA also makes use of Crowd, so nothing changed there.

I known we’ve been discussing moving to Java 6, but as long as we didn’t come to some conclusion and there’s nothing in the build that won’t compile under 1.5, I don’t see a reason to drop 1.5 support.

The Problem is the feature set of java 1.5. I use the Desktop Features from Java 1.6.

And EOL from Java 1.5 is 30. October. 2009.

cstux, I believe you are referring to Spark? I’ve got no issues with other projects moving to Java 6. I was referring to Openfire specifically.

Are there any plans to add Smack to nightly build process (and also adding links on the site)? Who will do this? Maybe Robin Collier? Or Niess? Btw, haven’t seen Guenther in the forums for a while.

Also for Openfire one should use JDK 6 to compile it, a new compiler usually has more features. For Openfire 4.0 one should finally remove support for Java 5 as it is really out-dated.

Hi wroot, you’re right. I’ve started to work on my diploma thesis and moved to another apartment, so I was busy the last months. Now I’m on the way back, read some threads, commits and tickets that I’ve missed…

Hopefully I’m soon up to date and can help

1 Like

I am willing to help out as well, but I am unfamiliar with Bamboo. I have used Hudson though, so hopefully it is as easy to use as that.

I was also wondering if it would be simpler if Smack was first mavenized. I think that would be an improvement over the current build scripts and included libraries.

I will be happy to add the correct Bamboo builds and configuration. If you look there now, you’ll see that most projects have a fully functional continuous integration plan. I’ll add nightlies shortly.