This documentation relates to an earlier version of Bamboo.
View

Unknown macro: {spacejump}

or visit the current documentation home.

This page describes how to configure a script builder for a Job.

When creating a new Job or configuring an existing one, you need to specify which builder should be used for executing the Job's builds. If you specify an Ant, Grails or Maven builder, you will also need to choose a JDK.

When creating a new Plan, you must specify a builder, which will used for the Plan's Default Job.

A builder is a 'build tool' external to Bamboo. Build tools are difficult to define, since the range of features can differ significantly from one build tool to the next. In essence though, a build tool is a source code compiling utility that generates compiled executable files (referred to as artifacts in Bamboo). Build tools typically have their own form of scripting language and an ability to manage dependencies correctly. Bamboo supports multiple builders. Once a builder is defined in the Bamboo system, it can then be specified in Plans and Jobs by a Bamboo administrator.

On this page:

Configuring a Script Builder for a Job

To configure a script builder for a Job:
(info) If you are creating a new Plan, start at step 2.

  1. Navigate to the Job's configuration pages, as described on Editing a Job.
  2. In the 'Builder' dropdown, select the script builder that you wish to configure for this plan (e.g. "Script1").
    (info) The builder that you select will become one of the plan's capability requirements. For details please see Configuring a Job's Requirements.
  3. The screen will refresh to display the builder settings specific to script builders:
    • 'Script' — Specify the location of the script file. This can be either relative to the repository root of the plan, or absolute. You can include variables (see Using Global or Build-specific Variables).
    • 'Argument' — Specify the relevant argument to pass to the script. Note that arguments which contain spaces must be quoted. You can include variables (see Using Global or Build-specific Variables).
  4. Update the system environment variables and working directory. These are optional settings:
    • 'System Environment Variables' (Optional) — Specify any additional* operating system environment variables you want to pass to your build; Please note, multiple variables must be separated with spaces, and parameters with spaces must be quoted (e.g 'ANT_OPTS=-Xms200m -Xmx700m'). You can also include Bamboo global or build-specific variables (see Using Global or Build-specific Variables).
      * i.e. additional to the existing environment variables (see Viewing Bamboo's System Information for a list). Note that existing environment variables are automatically available to the builder, thus you don't need to specify them in the 'System Environment Variables' field.
    • 'Working Sub Directory' (Optional) — A subdirectory relative to the Job build's root directory where Bamboo will execute your specified builder's commands. The Job build's root directory contains everything checked out from your Job's configured source repository. If you leave this field blank, Bamboo will look for the build files in the build root directory (which is assumed to be the Job build's Working Directory, as described in Locating Important Directories and Files). This option is useful, if your Job has a build script in a subdirectory and the builder needs to be run from within that subdirectory, in which case, you would type the name of that subdirectory in this field.
  5. Specify the following general build parameters:
    • 'The build will produce test results' — Select this check box if you want Bamboo to gather test results data for each build result. If selected, the following options will appear:
      (info) Bamboo requires test results to be XML files that are compatible with JUnit XML format. This format is also used by TestNG.
      • 'Look in the standard test results directory' radio button (Only available with Maven and Grails builders) — Select this option if Bamboo should look in the Builder's standard test results directory.
      • 'Specify custom results directories' radio button (Only available with Maven and Grails builders) — Select this option if the Builder will place generated test results in an alternative directory. If selected, the following will appear:
      • 'Specify custom results directories' field — Type the name of the test results directory (or multiple directories, separated by commas). You can also use Ant-style patterns such as **/test-reports/*.xml. Please specify file path relative to your Job build's root directory — do not specify an absolute path like /home/bamboouser/bamboo-home/xml-data/build-dir/JOB_KEY/.
        (warning) For Jobs that use CVS, the Job build's root directory is <bamboo-home>/xml-data/build-dir/JOB_KEY/<cvs-module>
  6. Have you been creating a new Plan or new Job until now?
    • 'Override default build hanging detection' — Select this check box if you want to override the default build hanging detection settings. These settings determine when a build hung event is thrown (e.g. you can configure your notifications to trigger from this event). If selected, the following options will appear:
      • 'Build Time Multiplier' — This setting is used to calculate the 'Expected Build Time' for the build (i.e. 'Expected Build Time' = 'Build Time Multiplier' multiplied by 'Average Build Time').
        (info) The 'Average Build Time' is calculated by Bamboo by using an average of previous build times.
      • 'Log Quiet Time' — This is the amount of time since Bamboo last recorded an entry in the build log for a build.
        (info) The 'Expected Build Time' and 'Log Quiet Time' must both be exceeded for Bamboo to throw the build hung event.
      • 'Build Queue Timeout' — This is the amount of time that a build will wait in a build queue before an timeout event is thrown. Setting this value will override the global build queue timeout setting (see Configuring the Job Build Queue Timeout Event).
    • 'NCover output will be produced' — Do not select this option. NCover is a code coverage tool that supports .NET projects.
    • 'Use Clover to collect Code Coverage for this build' — Select this check box if:
      • This Job will be building a Java-/Groovy-based project using a builder such as Ant, Maven or Grails.
      • You are running Atlassian Clover and want to collect code coverage data to view from within Bamboo (see Viewing the Clover Code-Coverage for a Build Result).
        If you select this check box, you can specify one of the following Clover 'Integration Options':
        • 'Automatically integrate Clover into this build' — For this option, you have two sub options — 'Generate a Clover Historical Report' and 'Generate a JSON report'. The Clover Historical Report shows the current coverage results compared with previous Clover code coverage reports. The JSON report gives the Clover results in a format ready for embedding into applications or external report views.
          You will also need to insert a Clover license (evaluation licenses are available) into the field provided.
          (info) Please see Enabling the Clover Plugin for more information.
        • 'Clover is already integrated into this build and a clover.xml file will be produced' — Use this option when you already have Clover-for-Ant or Clover-for-Maven configured to generate a report. You will also need to specify where the Clover XML report is being generated, under 'Clover XML Location'. For this, specify the name of the directory (including path) where Bamboo will look for the XML report output file from Clover. Please specify a file path relative to your Job build's root directory, for example:
          target/site/clover/clover.xml
          (warning) Do not specify an absolute path.
  7. Click the 'Save' button to save your changes.

Notes

Related Topics

Specifying a Builder
Editing a Job