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.