The build definition
As we have seen in the Continuum build life cycle overview earlier, Continuum uses build definitions for building the projects.
We can think of build definitions as instructions for Continuum on how to build the project. There are two levels of build definition: project group level and project level.
Project group build definition
Let’s go back to the Project Group Summary page of our centrepoint application and click on the Build Definitions tab. Continuum configures a default build definition for each project group created. The content of the build definition depends on the type of the project. For Maven 2 projects, goals such as clean install and clean deploy need to be defined while Ant and shell projects do not require this. Instead, they configure their respective command-line goals.
As we can see from the Project Group Build Definition of our Centrepoint project group below, the goals to be executed for the build can be configured as well as the schedule of its execution.
The default Project Group Build Definition has clean install as its goals. Having install as a goal means that the project’s artifacts will only be available locally (in the local Maven repository) to where our Continuum instance is running. Consumers of the project (for example, the project’s Quality Assurance team) will not necessarily have permission to access the machine itself and it is out of the question to obtain the latest build from the local repository. Instead, the right way to do is to set up a deployment repository for snapshot artifacts, configure Continuum to build the project, and deploy the built artifacts to the snapshot repository, so that there is a new build each day that can be consumed by the QA team for testing.
...
<distributionManagement>
<repository>
<id>releases</id>
<name>Archiva Managed Releases Repository</name>
<url>http://localhost:8081/archiva/repository/releases</url>
<layout>default</layout>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Archiva Managed Snapshots Repository</name>
<url>http://localhost:8081/archiva/repository/snapshots</url>
<uniqueVersion>true</uniqueVersion>
<layout>default</layout>
</snapshotRepository>
</distributionManagement>
...
We don’t need to configure anything else in our settings.xml and security-settings.xml.
Now let’s create a new build definition for our Centrepoint project group. Click the Add button on the group build definitions page, then fill in the Build Definition as follows:
The POM filename is the actual filename of our project’s pom.xml that will be used for the build. The Goals are the goals we want to execute when using this build definition. As we want our artifacts to be available to the snapshots repository, we will set clean deploy as our goals. The Arguments specify the additional arguments that will be used when building the project. In our case, these are Maven 2 arguments, as our project is a Maven 2 project. If you had wanted to do a fresh checkout instead of just updating from the source repository during the build, you would tick the Build Fresh checkbox.
One behavior of Continuum to take note of is that if there were no changes to the SCM in the last build; Continuum would no longer build the project. This sometimes causes people to panic and think their CI is broken, but it is actually not. When you think about it, it makes sense that this is the default behavior. There were no changes in the code, so why build it? To countermand this behavior, you would tick the Always Build checkbox in the build definition. This would tell Continuum to always build the project whether there were any changes in the SCM or not.
The Is it default? field signifies that the build definition is the default one that will be used when the project build is explicitly triggered (forced build) from the Project Group Summary and Project Summary pages. This field can only be edited if there are multiple build definitions defined for the project.
We will discuss schedules next, but for now we will just use the DEFAULT_SCHEDULE. The same goes for Build Environment. We will cover this at the end of this article. For now, we will leave as it is.
As for the last two fields, they simply specify the type of project the build definition is for and the description of the build definition respectively.
Click Save and our build definition is created.
Now for each project group, we can define multiple build definitions and attach it to a schedule. A schedule is just a plain old schedule of when a build will be triggered or executed. The diagram below, which Wendy Smoak created for Continuum effectively shows how the project group, build definitions, schedules, build queues, and notifiers (which we will discuss later on) work together.
Going back to the schedules, a default schedule running every hour is already pre-defined in Continuum and that is where the default build definition is attached. We will create a schedule for our project’s nightly builds where we will attach the build definition that we created so that there is a fresh snapshot each day which the QA team can test for all the changes or fixes in the code from the previous day. From the Schedules tab on the left you can add a new schedule. Fill in the form as follows:
The important field to take note of in the Schedule is the Cron Expression.
A Cron Expression is a representation of a time or times at certain intervals. This is used typically to fire or trigger a schedule to do or execute something.
From the Cron Expression we have specified above, we are configuring our schedule to build each night at 12 midnight.
The other field to take note of is the Build Queue. This simply defines where the project(s) attached to this schedule will be queued. If no build queue were set, Continuum would use the DEFAULT_BUILD_QUEUE.
Save the schedule that we created. Go back to Centrepoint’s Build Definitions tab, edit the Project Group Build Definition we created earlier and attach it to our NIGHTLY_BUILDS schedule.
When setting a schedule, sometimes an hour is too long to wait. If a problem occurs it may be drowned out by other changes, or the developer may have switched context. Builds should be kept short and scheduled frequently. Long-running tasks, such as performance and functional tests, and nightly builds can be run on separate schedules.
To demonstrate how build definitions are used, click the build icon (third column from the right) of our snapshot deployment build definition. After the projects in the group have finished building, go back to the Project Group Summary page and click on the build number link (fifth column from the left) of one of the projects. Clicking on the build number leads us to the build result of that specific build including the build definition used and the build output. We will cover build results in the succeeding sections. You can also check the snapshots repository at http://localhost:8081/archiva/repository/snapshots to see that the projects were deployed.
Project build definition
A project level build definition is essentially the same as a project group build definition—it could be tied to a schedule and everything. The only difference is that it’s on a per project level. Therefore, when only that project was triggered to be built, continuum would use the default project level build definition.
The notifiers
We mentioned earlier in the article that one of the benefits of using a CI server is that when the build breaks, the project members would immediately know of it. This is where notifiers come in. Notifiers are a configuration in the CI, which send out notifications to the project members regarding the status of the build.
Different types of notifiers
In Continuum, there are five types of notifiers that can be configured. These are the:
- Mail notifier: The mail notifier sends out an email to a specific address regarding the status of the build. For the mail notifier to work, it’s good to keep in mind to set up a mail server first. Remember, we did this whilst installing prerequisites at the beginning of the article.
- IRC notifier: This notifier sends out a message to a specific IRC channel alerting the channel of the project’s build condition.
- Jabber notifier: This notifier sends out a message to a specific Jabber account.
- MSN notifier: This notifier sends out a message to a specific MSN account.
- Wagon notifier: This notifier deploys the build results to a specific URL (for example, to the project’s site) using Wagon.
These notifiers can be configured to notify the project team on certain conditions of the build. They can be set up to Send on Success, Send on Failure, Send on Error, and/or Send on Warning as seen in the following screenshot:
They are self-descriptive, but we will give each one a quick run through:
- Send on Success: Send out a notification if the build was successful.
- Send on Failure: “Code red! Code red! Code RED!!!”. Need we say more? Okay, just to elaborate… a notification will be sent out when the build fails. By fail, we mean that a problem was encountered during build execution. This can be a compile failure, a test failure, or simply a dependency not being found.
- Send on Error: A notification will be sent out when there was an error outside of the build execution. A good example of this is when the source repository goes offline and Continuum cannot update its working copy.
- Send on Warning: A notification will be sent out if the build was not a successful build, a failed build, or an erroneous build.
A notification is sent only when a project’s state is modified. For example, if the previous state of all the projects in the group is SUCCESS and on the next build, all the projects in the entire group were built successfully again, no notification will be sent. However, if the second build of one of the projects failed (state is FAILURE), a notification will be sent specific to that project.
The Send a mail to latest committers field for the Mail Notifier tells Continuum to send a notification mail to those developers who committed changes to the source repository as part of the last build. The Mail Recipient Address does not have any effect on the Send a mail to latest committers as the email addresses where the notification mail will be sent are retrieved from the list of project developers.
Like build definitions, notifiers can also be configured at the project group level and/or at the project level. Notifiers are cumulative, which means notifiers configured at the group level always takes effect whether or not there are notifiers configured at the project level. This is similar to the co
Now, let’s create a group mail notifier for our centrepoint application. In our exercise, we will use our own valid email address for the mail notifier. We want to know everything that is happening to our project build so we tick all the checkboxes except for Send a mail to latest committers (we don’t have usernames in our SVN repository so we don’t have any use for this). Let’s build our project by pressing the Build All Projects button on the Project Group Summary page. We should get a successful build and the build states of all the projects in the group should show the SUCCESS icon. However, no notification mail was sent. This is because there were not any changes in the build state nor were there any changes in SVN.
