Overview
Built-in projects are a class of pulse™ projects that are configured completely via the web interface. They offer the full flexibility of the pulse™ build core through the web interface. When creating a new project via the add project wizard, two types of built-in project are listed as choices:
Note that both choices actually create the same type of project, but single-step projects are handled specially by the wizard to make them easier to configure.
Advantages
Built-in projects have the following advantages over pulse file projects:
- They are easier to configure, especially when you first start using a new pulse™ server.
- You can configure your project in a few simple steps and without checking in any additional files to your SCM.
- They can take full advantage of templated configuration to share configuration (other sharing mechanisms may be used in pulse files).
As of version 2.1, built-in projects expose the full flexibility of the pulse™ build core, so configuration of a pulse file project should never be necessary. Rather, you can choose to configure via the web interface or a pulse file according to your preference.
Configuration
Both single- and multi-step projects use the same project type to configure their recipes. This type allows any number of recipes, commands and artifacts to be configured for your project. To access this configuration, go to the configuration view for the project, then select the "recipes, commands and artifacts" tree item.
Recipes
Recipes are sequences of commands used to build a project. All projects must include at least one recipe that describes how the project is to be built. Multiple recipes may be used to describe variations of the build which may be used in different build stages.
Commands
Commands are single units of work in a build. All non-trivial recipes include at least one command. Commands are frequently used to run external build tools such as make or ant. Popular tools are supported via specialised commands, although any tool can be executed using the executable command. Supported commands include:
Artifacts
Artifacts are used to capture important output from the build. Common examples of artifacts include command output (standard out and error), binary files (executables, libraries, JAR files) and reports (unit test reports, test coverage reports). Artifacts are configured for each command, and are captured just after that command completes.
In addition to capturing artifacts, you may also apply post-processing to them. Post-processing is used to extract features such as errors and warnings, as well as capture the output of test results.
Pulse supports the following types of artifact:
| Type |
Description |
| Directory |
A collection of files nested underneath a directory, e.g. a directory of test reports. |
| File |
A single file, e.g. a binary produced by the build. |
| Link |
A link to an external artifact, e.g. a file published on an external server. |
| Output |
Output (standard output and error) from the build command. This artifact is implicit, and post-processing is configured as part of the command. |
Migrating to Pulse File Projects
Built-in projects are implemented on top of the same core as pulse file projects. In fact, a pulse file is created based on the project configuration whenever a built-in project is built. This pulse file may be viewed via the web interface in the results for the build. This provides a starting point for you to create your own pulse file for the project. If you wish to migrate your project from a built-in type to a pulse file project, you can use the "convert to custom project" or "convert to versioned project" link on the hierarchy view for the project.
