This documentation relates to an earlier version of Bamboo.
View

Unknown macro: {spacejump}

or visit the current documentation home.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The instructions on this page describe how to configure a CVS source repository for either a Plan or a Job.

When creating a new Plan, you must define a 'default source repository'. This includes specifying the source repository settings (including the repository's location), any required authentication details and other options specific to the type of repository. You can also specify the type of build strategy the Plan will use.

The 'default source repository' is initially used by the Plan's 'Default Job' and can also be used by other Jobs added to this Plan. You can override the default repository for any Job, by defining a custom source repository for it (after creating the Plan).

On this page:

Configuring a CVS Source Repository

The instructions in this section apply to configuring a source repository for both Plans and Jobs.

To configure a CVS source repository:
(info) If you are creating a new Plan or new Job, or have come from the Editing a Plan or Editing a Job topics, start at step 4.

  1. Navigate to the source repository settings for a Plan or Job, as described on Specifying the Source Repository for a Plan and Specifying the Source Repository for a Job respectively.
  2. CVS configuration
    • 'Use Plan's Repository' (Only available when configuring a Job) — Select this option if you wish to use the 'default source repository' of the Plan to which your Job belongs. If you select this option, you do not need to configure any further source repository options below, although if you are creating a new Job, continue with the Builder Configuration section of Creating a New Job.
    • 'Repository' — select 'CVS'.
    • 'CVS Root' — Type the full path to your CVS repository root (e.g. ':pserver:me@cvs.atlassian.com:/cvsroot/atlassian'). Bamboo supports pserver, ext (ssh) and local repository access methods. Note that you can use global variables in this field (see Using Global or Build-specific Variables).
      (info) If you are importing a Maven 2 Project, this location should contain your project's pom.xml file.
    • 'Authentication Type' — Select either 'Password' or 'SSH'.
      • If you select 'Password', the following fields will appear:
        • 'Password' (Optional) — Type the password for your CVS repository.
        • 'Change Password' (Only available after first saving the Plan/Job with a password) — Select this check box if you want to change the password that is used to access the CVS repository.
      • If you select 'SSH', the following fields will appear:
        • 'Private Key' — Type the absolute path of your SSH private key.
        • 'Passphrase' — Type the passphrase for your SSH private key.
        • 'Change Passphrase' (Only available after first saving the Plan/Job with a passphrase) — Select this check box if you want to change the password for your SSH private key.
    • 'Quiet Period' (Only available when configuring an existing Plan) — This setting is used to avoid starting a build while someone is in mid-checkin. Bamboo will only initiate a build for this plan when no more changes are detected within the Quiet Period following the last known change. Type the number of seconds Bamboo should wait. Please note that this parameter is mandatory for CVS, as CVS allows partial checkouts.
    • 'Module' — Type the name of the CVS module that contains the source-code.
      (info) Currently Bamboo has limited support for CVS ampersand modules. To use an ampersand module, you will need to define a regular module with the same name as the ampersand module (since Bamboo expects there to be a directory with the specified checkout module name). For example:
      1. Create a module (e.g. allbuilds).
      2. Define an ampersand module with the same name. (The ampersand module can be empty.)
      3. In the 'Module' field, enter the following: allbuilds allbuilds &project2 &project2 &project3
    • 'Version of module' — Select either 'HEAD' or 'Branch/Tag'. If you select 'Branch/Tag', the following field will appear:
  3. Are you creating/cloning a new Plan or a new Job?
    • If you are creating a new Plan, continue with the Build Strategy section of Creating a New Plan.
    • If you are creating a new Job, continue with the Builder Configuration section of Creating a New Job.
    • If you are cloning an existing Plan or Job, continue on with the next step.
    • If you are importing a Maven 2 project, perform the Web Repository section of the Common Repository Configuration step below, before returning to the Enable this Plan section of Import a Maven 2 Project.
  4. Common Repository Configuration (Only available when configuring an existing Plan/Job)

    • 'Force Clean Build:' (Optional) — You can force Bamboo to remove the source directory and check it out again prior to the Plan/Job build being built by selecting this option. Please note that this will greatly increase the time it takes to complete a build.
    • 'Clean working directory after each build:' (Optional) — You can force Bamboo to remove the source directory after the Plan/Job is completed building by selecting this option. Please note that this may increase build times but saves on disk space.
    • 'Include/Exclude Files:' (Only available when configuring a Plan) — You can specify a particular inclusion or exclusion pattern for file changes to be detected. If you select an option other than 'None', the following field will appear:
      • 'File Pattern:' — The regular expression for file changes which you wish to include/exclude.
    • 'Web Repository:' — Select the type of web repository ('None', 'Generic Web Repository', 'Mercurial Web Repository', 'FishEye') to be associated with this build. You will be able to view code changes related to your build via the build results.
      (info) Only a subset of Web Repository options are available for your chosen repository type.
      • If 'Generic Web Repository' is selected:
        • 'Web Repository URL' — If your source repository can be accessed via a web browser, you can specify the URL of the source repository here. If you specify a Web Repository URL, then links to relevant files will be displayed in the 'Code Changes' section of a build result.
        • 'Web Repository Module' — The repository name of the Plan/Job, if the above Web Repository URL points to multiple repositories.
      • If 'Mercurial Web Repository' is selected:
        • 'Mercurial Web Repository Viewer Scheme' — Choose between using the BitBucket Web Repository Scheme (if you use BitBucket) or Mercurial's own default web server (Default Web Repository Scheme (hgserve)).
      • If 'FishEye' is selected:
        • 'FishEye URL' — The URL of your FishEye repository (e.g. 'https://atlaseye.atlassian.com/').
        • 'Repository Name' — The name of your FishEye repository (e.g. 'Bamboo'). This is effectively the alias for your repository path.
        • 'Repository Path' — The path for your FishEye repository (e.g. '/atlassian/bamboo/').

          How do I determine my Repository Path?

          If you have previously run builds with changes from your repository, the easiest way of determining your repository path is to view the code changes and copy the path from the start of the path of one of the changed files, up to (but not including) the appropriate root directory. The root directories for repositories are the ones shown by FishEye when browsing a repository (e.g. trunk)). For example, if a code change listed /atlassian/bamboo/trunk/bamboo-acceptance-test/pom.xml, the path would be /atlassian/bamboo/.
          If you have not previously run builds with changes from your repository, you will need to ask your FishEye administrator for the repository path indexed by FishEye.

    • 'Build Strategy' (Only available when configuring a Plan) — Choose one of the build strategy options (listed below), which will be used for triggering the execution of this Plan. You can change the Build Strategy at a later point in time as required.
      (warning) You may need to configure other options specific to your chosen build strategy.
      (warning) If you select Manual & dependent builds only when creating a new Plan, an initial build will not automatically be run. You can force an initial build to be executed automatically by adding the fire.initial.build.for.manual.strategy to your bamboo.cfg.xml file as described in Configuring System Properties.
  5. Click the 'Save' button to save your changes.


Screenshot above: Source Repository — CVS

Appendix - Build Strategies

This table lists Bamboo's available build strategies that determine how the execution of a plan (i.e. a build) is triggered. Each build strategy has other options (listed at the far right of this table), which may also require configuration.

Build strategy option

Description

Reason for choosing

Other build strategy-specific options

Polling the Repository for changes

Bamboo will 'poll' the source code repository (specified above) at regular intervals. If Bamboo detects a change to any code in this repository, a build of this plan will be triggered.

This is the simplest option as it requires no further configuration. However, for every plan that uses this build strategy option, your source code management system must service either a 'check out' or 'update' command at the specified polling frequency (right), even if no code has changed in the repository.

Polling Frequency
(in seconds)
Defines the interval between each poll for this plan.

The repository triggers the build when changes are committed

Bamboo will wait to receive a message from the source code repository (specified above) about any code changes in this repository. When Bamboo receives such a message, Bamboo will trigger a build of this plan.

This option minimises server load as message events are sent only when code changes to this repository are committed. However, you must configure your source code management system to send message events to Bamboo about code changes in this repository.

Trigger IP Address
Use only if you need to specify an IP address which is different from that of the source code repository's server.

Cron Based Scheduling

Bamboo will trigger a build of this plan based on a Cron expression.

This option allows you to schedule builds when server load is likely to be minimal, for example, outside office hours. Scheduled builds are triggered irrespective of any code changes in the source code repository.

Cron Expression
Consists of 6 mandatory and one optional field in the order: seconds, minutes, hours, day-of-month, month, day-of-week and (optional) year. For more information about Cron expressions, please refer to How do I construct a cron expression in Bamboo?

Single daily build

Bamboo will trigger a build of this plan once per day at a specified time.

This option is suitable if a build of this plan takes a long time to complete. Scheduled builds are triggered irrespective of any code changes in the source code repository.

Build Time
The time in 24-hour format (hh:mm) at which Bamboo will trigger a build of this plan.

Manual & dependent builds only

Bamboo only triggers a build of this plan when the user chooses this function manually or through a build dependency.

This option is suitable if a build of this plan will fail, perhaps due to source code problems of failing tests. This frees up Bamboo agents to build other plans which are less likely to fail.

There are no other options to configure for this build strategy.

Notes

Related Topics

Specifying the Source Repository for a Plan
Specifying the Source Repository for a Job

  • No labels