Continuous Integration

Every module have an associate build in our CI server, https://ci.openmrs.org/allPlans.action . On every commit to master, a build is triggered; if all the tests pass, the SNAPSHOT maven artifacts will be deployed to http://mavenrepo.openmrs.org/nexus/index.html (remote maven).

Some builds are configured to trigger other plans after successfully completing; you can get the full picture in Build > Build Dependencies.The majority of the builds are configured to send success and fail notifications to dev-refapp@openmrs.org.

Some builds are already configured to execute maven releases from Bamboo.

We also have a Continuous Deployment set up.

Bamboo agents - running your builds

The Bamboo server, the one discovering code changes and collecting tests results, is a single server. But the builds actually run not in the server, but in Bamboo agents instead (in Jenkins they would be called 'slaves').

Which agent ran my build?

We have two machines dedicated to that, each one have two agents, which means that 4 builds can be running at the same time at a certain time. Check Build > Build Activity for more details.

Both machines are Ubuntu 14.04. The agents are provisioned using puppet, so do not install anything from the build. Each agent inside the same machine will run isolated in a different user (bamboo-agent-1 and bamboo-agent-2), having isolated maven local repository (~/.m2/repository) and default java tmp dir (~/bamboo-agent/.agent_tmp). Both the private tmp diretories and the main /tmp will be cleaned up regularly.

Unit tests and tmp folder

When running unit and integration tests from Maven (surefire maven plugin or failsafe plugin), by default the temp folder defined per Bamboo agent will be ignored. Surefire by default fork the JVM when running the tests, and java.io.tmp is not passed to the forked JVM

In case your build needs to create files using a specific name in /tmp, make sure so configure surefire to pass the received tmp configuration to the forked JVM:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <!-- Bamboo agents require a different tmp folder -->
        <systemPropertyVariables>
           <java.io.tmpdir>${java.io.tmpdir}</java.io.tmpdir>
        </systemPropertyVariables>
    </configuration>
</plugin>

Otherwise, different users can try to run your build, and the second one won't have permission to override or delete the file that already exists.

Build reliability

Before every build, a plugin called Predator will delete old build working directories. But if the same agent runs the same build twice in a row, left overs from previous runs can still be there. It's possible to mark 'Force clean directory' in the Bamboo checkout task if that's important.
The very same plugin removes all SNAPSHOTs from the maven local repository. Refer to Continuous Integration for more details. The deploying snapshots blogpost explains the big picture, but the idea is that if the snapshot doesn't exist anymore, we want to fail fast.
Maven is configured with updatePolicy to always. Which means that if there's a new version of a plugin or dependency and you defined a range version (or no version at all), the very next build will pick the new version (the same effect as having -U in all the build)

CI Staging Environment

Click here to expand...

In case you need to test something in the Bamboo agents, check openmrs-contrib-bambooagent has a vagrant configuration (so, vagrant up is all you need). The same process is described in Developer How-To Launch a Local Instance of the Reference Application.

If you feel like doing some experimentation with Bamboo, check https://ci-stg.openmrs.org/ . In case you need build agents, you can always configure your vagrant box to ci-stg (in install.pp).