The instructions on this page describe how to configure a Perforce 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).
Configuring a Perforce Source Repository
The instructions in this section apply to configuring a source repository for both Plans and Jobs.
To configure a Perforce repository:
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.
- 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.
- Perforce 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 'Perforce'.
- 'Port' — Type either the port to which the Perforce client will connect, or the Perforce server itself. This is the Perforce P4PORT environment variable that tells Bamboo which p4d (Perforce server) to use.
- 'Client (Workspace)' (3) — The name of the Perforce Client Workspace which Bamboo will use. The Client Workspace determines which portions of the depot are visible in your Workspace Tree.
Do not create two Plans/Jobs that use the same client (e.g. one client set to manage, the other client set to not manage). This setup will create major issues in your builds.
- 'Depot View' — The client view of the depot that contains the source code files for this Plan/Job. This is typically in the form
//<clientname>/<workspace_mapping>/...
For details please see the Perforce User's Guide.
- Bamboo sets the client root to its working directory, which means that code will be checked out to the 'working directory/
<workspace_mapping>
' location. Please take note of this, when specifying the 'Artifact Copy Pattern' for your Build Artifacts.)
- 'Location of POM file' (Only available when importing a Maven 2 project) — Type the path to your project's
pom.xml
file which is relative to the root of your Perforce Client (Workspace) (defined above).
- 'Username' (Optional) — The Perforce username that Bamboo will use when it accesses the server ('Port'). Leave this field blank if you want Bamboo to use the default Perforce user (i.e. the OS username).
- 'Password' (Optional) — Type the password required by the Perforce username (if applicable).
- '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 Perforce repository.
- 'Let Bamboo manage your workspace' (4) — This field indicates whether or not you want Bamboo to manage your workspace.
- 'Enable Quiet Period:' (Only available when configuring an existing Plan) — Select this setting to set Quiet Period parameters for the Plan's build. Upon selecting this option, the following fields become available:
- 'Quiet Period:' — 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.
- 'Maximum Retries:' — You can specify how many times Bamboo should check for new changes using the Quiet Period parameter before initiating a build. For example, if you have set the 'Quiet Period' to '10' seconds then Bamboo will check if a checkout has occurred in the last 10 seconds. If you have then specified 'Maximum Retries:' as '5', then Bamboo will perform this check five times before initiating the build, regardless of any activity during the Quiet Period of the last check.
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.
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.
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/
').
- '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.
You may need to configure other options specific to your chosen build strategy.
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.
Click the 'Save' button to save your changes.

Screenshot above: Source Repository — Perforce
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 |
説明 |
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? |
毎日 1 回のビルド |
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. |
注意
- If you wish to build Plans on your Bamboo server and remote agents using a Perforce repository, you need to specify the location of the Perforce P4 client application for your Bamboo server and each remote agent that uses Perforce. These locations are set by specifying:
- a mandatory local server Perforce capability for your Bamboo server and
- agent-specific remote Perforce capabilities for each of your remote agents using Perforce.
You will not be able to create Plans/Jobs that use a Perforce repository without specifying the shared local Perforce capability first. Read more about configuring a Perforce capability.
- Keep your Perforce configuration up to date — If you are using Perforce as your repository, you must ensure your Perforce configuration in Bamboo is in sync with any changes to your Perforce repository (such as client, depot or user credential changes). If not, your Perforce repository changes may cause unexpected behaviour in Bamboo when Bamboo tries to access the repository. See the notes in the configuration instructions below for further details.
- Issue when running Bamboo with Perforce prior to Bamboo 2.0.7 — A known issue exists when running Bamboo with Perforce prior to Bamboo 2.0.7 (See BAM-2866 and BAM-2849). If you change the name of your Perforce client (i.e. via an update) without updating your Perforce configuration in Bamboo, Bamboo will not be able to find the Perforce client to run against. Perforce will then create a default client in your running directory. This can lead to situations where Bamboo will attempt to clear out data from your running directory (e.g. force build). To avoid this problem, ensure that you update the 'Client' in your Perforce configuration whenever you change your Perforce client.
- Please be aware of the following implications when either letting Bamboo manage or preventing Bamboo from managing your workspace:
- If you let Bamboo manage your workspace,
- We recommend this configuration if your Jobs will be running on many different machines or different operating systems, as Bamboo sets the client root for you.
- Bamboo will make configuration changes to the Client Workspace to manage builds (e.g. Bamboo will modify the
host
and root
). You need to ensure that you enter a Client Workspace in the 'Client' field that will be used solely for Bamboo.
- Under this configuration, you should configure one client per Job to avoid conflicts when updating the client root.
- If you do not let Bamboo manage your workspace,
- We recommend this configuration if you wish to reuse your client for several Jobs, as Bamboo will retrieve the client root directory from Perforce and use it to run builds.
Setting the client root in Perforce: We strongly recommend that you choose a directory that is dedicated for Bamboo's use only, when you are specifying the client root in your Perforce repository. This directory may get cleaned (i.e. files and sub-directories deleted) if you choose to force clean builds.
- Under this configuration, you need to ensure that the client root directory exists on all machines that the Job will be built on.
- Please note that alternate roots does not currently work in Bamboo. See issue BAM-2377 for further details.
Specifying the Source Repository for a Plan
Specifying the Source Repository for a Job