Introduction
The pulse™ master server stores all persistent information in the data directory.This includes both configuration and build results. On the master and agents data directory is also used as a working area for builds in progress, and to hold working copies for incremental builds. This cookbook entry describes the layout and contents of the data directory.
Layout
Each subdirectory of the data directory is described in a subsection below.
backups
Stores automatically-created backups of your pulse™ database, in zip archives named auto-backup-<version>.zip. When you upgrade pulse™, sometimes schema changes will be made to your existing database. In this case, pulse™ will automatically take a backup of your database first. These backups may be deleted once you are happy with the operation of your upgraded server. However, it is advisable to keep at least the most recent backup, and we would encourage you to use your own bacup mechanism external to pulse™ for maximum reliability. Master only.
config
On the pulse™ master, stores some server-level configuration information and customised user templates. This does not include the bulk of the configuration (e.g. projects, users), which is stored in the database. Files and subdirectories include:
| File |
Description |
| database.properties |
Configures the database that is used by pulse™. By default, refers to the embedded database. |
| pulse.properties |
Stores configuration information from the administration > settings page. |
| service.token |
Shared security token used for agent communications. |
| templates |
Directory used to store all user-customised templates. |
Agents also have a config directory, used to store the service.token.
database
Stores the embedded database. As the database stores the bulk of the configuration information, a minimal backup should include this directory. Master only.
projects
Stores the build artifacts for each project on the master. This includes build logs, all captured artifacts and full test results. The layout is something like:
- projects/
- <project id>/
- <build number>/
- pulse.xml
- <recipe result id>/
- base/ - the working copy for the stage, if retained
- output/ - the artifacts and the full test results for the stage
The normal way to control the size of this directory is using cleanup rules. Note that capturing the working copy will often require a lot of space. This can be disabled for a build specification by ensuring the "retain working copy" option is not checked.
The contents of this directory are not essential for a minimal backup. Pulse can be restored without the full build data, although the logs, artifacts and full test results will be lost.
recipes
A temporary working space for builds in progress on the pulse™ master and agents. Each stage will be executed in a subdirectory named for the recipe id. The contents of this subdirectory are temporary and it is removed at the end of the stage. The contents of this directory need never be backed up, and may be safely deleted when there are no builds in progress.
users
This directory is analogous to the projects directory, but stores personal build results rather than project build results. The files stored are the same, with the addition of the patches uploaded by the user for personal builds in the users/<user id>/patches subdirectory.
work
Used on both master and agents. Stores a persistent work area used for build specifications that employ the "clean update" or "incremental update" checkout scheme. In the case of the former, source code is checked out to this area but is then copied into the temporary recipes/ area for building. In the case of the latter, the builds happen in place in this work area. The layout is something like:
- work/
- <project name>/
- <specification name>/
- (checked out source code)
The contents of this directory need not be backed up and may be safely deleted when no builds are in progress. In this case, a clean checkout will be used for the next build. Note that this directory can be quite large, especially when the "incremental update" scheme is used, as built binaries generally consume significant space.