Overview
A project in pulse™ is used to describe a specific type of build for a software project. For each configuration of each code line that you want to automatically build and test, you should add a new project to your pulse™ server. In this case configurations might include: continuous (run on every checkin), nightly (run once a day) and release (run when ready to ship a new version). Simple software projects may have just one code line, but most projects consist of multiple code lines, commonly represented as branches in the project's SCM. Projects are at the core of pulse™; when using your pulse™ server you will be mostly concerned with viewing and managing projects and builds of those projects.
Managing Projects
Projects in pulse™ are templated, meaning that they are configured hierarchically so that you can avoid duplicate configuration. Project templates are used for sharing configuration, whereas concrete projects are used to run builds and generate reports in the pulse™ web interface.
You can view a summary of all concrete projects on your pulse™ server in the "browse" section of the web interface. This section provides a convenient view of the most recent status for all concrete projects. By clicking on the project name, you will be taken to the project home page. This page is the central place for all current information about the project.
Adding New Projects
Projects can be added to your pulse™ server using the "add project wizard". This wizard can be accessed by navigating to the hierarchy view for the desired parent template and clicking the "add new" link. Refer to the Understanding Templates page for more information about how to add new templates and concrete projects.
You can also create a new project by cloning a current project. This is convenient when creating multiple projects with similar configuration. Clones can either by straight copies, or smart clones, where the shared configuration is extract to a template. To create a project this way, navigate to the hierarchy view for the existing project, and click the "smart clone" or "clone" link as desired.
Deleting Projects
If you ever wish to delete a project, you can do so using the "delete" link on the hierarchy view for the project. Note that when a project is deleted, the entire build history for the project is also deleted. Removing all of the stored build information from disk may take several minutes (it is done in the background).
Organising Projects
If you have a large number of projects, it may be useful to organise them into logical groups. Projects can be organised into groups by giving them labels. Labels are a convenient way to express groups as they are inherited from template parents. Projects may be optionally grouped by label both in the "browse" section of the interface, and on your dashboard. For more information, refer to the Project Labels page.
Project Types
pulse™ supports multiple types of projects. These project types fall into two categories:
| Type |
Description |
| Built-in Projects |
Projects that use directly-supported build tools and are completely configured via the web interface. These projects are the easiest to configure, and are a great way to start using your pulse™ server. |
| Pulse File Projects |
Projects that have their recipes described by pulse files. These are the most flexible projects, and although they take more intial effort to configure, offer advantages over built-in projects. |
Built-in projects can be further divided into the following types:
Pulse file projects can also be further divided:
| Type |
Description |
| Custom Projects |
A pulse™ file project where the pulse™ file is edited and stored on the pulse™ server. |
| Versioned Projects |
A pulse™ file project where the pulse™ file is stored and versioned with your code in your SCM. |
Project Configuration
The configuration for a project includes:
| Section |
Description |
| basics |
Basic project details, such as the project name, description and URL. |
| type |
Type-specific configuration, such as the location of an Apache Ant build file (refer to the types above). |
| artifacts |
Files and directories captured and post-processed after commands are executed. |
| required resources |
Resources required on agents to be able to build the project. |
| properties |
Properties introduced into the builds for the project. |
| build stages |
Defining which recipes are run on which agents when building the project. |
| build options |
General options controlling builds of the project. |
| build hooks |
Tasks invoked at certain hook points in a build (e.g. tagging source code). |
| scm |
The project's SCM details, including the type of SCM server and client details. |
| change viewer |
An optional reference to an external tool for viewing changelist and diff information. |
| commit message transformers |
Transformers used to filter SCM commit messages, for example to link text in messages to external tools. |
| labels |
Labels used to logically categories projects. |
| permissions |
Project access restrictions, which decide who can do what to the project. |
| cleanup rules |
Cleanup rules describe when to clean up old build results. |
| triggers |
Triggers determine when the project is built. |
All of these settings may be configured in the "administration" section of the web interface via the "configuration view" for the project.
