Integrating TeamCity with Perforce
This article describes how to integrate TeamCity with Perforce Helix Core to:
Build sources of projects stored in a Helix Core repository.
Use Perforce streams as feature branches and build their sources independently of each other.
Pre-test and pre-build files in shelved changelists.
Apply automatic labels to sources.
Report build statuses to code reviews in Perforce Helix Swarm.
TeamCity supports Perforce Helix Core servers/clients starting from Helix Core 2017.1
A Perforce Helix Core client must be installed on the TeamCity server machine.
The path to the Perforce client must be added to the
Alternatively, a full path to
p4could be set via the internal property
teamcity.perforce.customP4Path. The property value must include the
Running Builds on Perforce Helix Core Sources
To be able to run builds on project sources stored in Perforce Helix Core and to use all the features described in this article, you need to perform two procedures:
Create a dedicated project in TeamCity:
Go to Administration | Projects and click Create project.
Note that this will add the project right under the Root project. Alternatively, you can add it under any other existing project.
Enter the Name and ID of the project.
Create a Perforce VCS root:
In the Project Settings, go to VCS Roots.
Click Create VCS root.
Choose Perforce Helix Core as a VCS type.
Configure the root's settings as described in this article.
After the project and Perforce root are configured, you can proceed with adding build configurations and running builds.
Running Builds on Perforce Streams
TeamCity can monitor commits in Perforce streams and work with them as with regular feature branches.
If a Perforce root is configured to use the Stream mode, you can enable the feature branches support in the root settings. After it is enabled, all streams which have the specified main stream as a parent will be included into the set of feature branches processed by TeamCity. To include only specific streams to this set, edit the branch specification to filter these streams. Each filter rule should start with a new line. The syntax is
+|-:stream_name. For example, use
+://stream-depot/* to monitor only streams located in the
stream-depot depot, where
* (for example,
master) is a logical branch name.
TeamCity can process task streams as well, but it only detects new task streams if there is a non-merge commit made to them.
Running Builds on Streams from IntelliJ IDE
You can launch a remote build run from IntelliJ-platform IDEs, but only if a stream has been already detected by TeamCity. The TeamCity Remote Run plugin tries to deduce the correct stream according to the depot paths of the files in the IDE's working copy.
For instance, if a file path in the working copy starts with
//depot/stream1/some/path, TeamCity will try finding the
//depot/stream1 stream and starting the remote run there. If you have modified a file from another stream (imported into the working copy) and want to enforce a build in a particular stream, you need to specify a configuration parameter
teamcity.build.branch when triggering the remote run.
Cleaning Stream Workspaces
To properly process task streams, TeamCity needs to create dedicated workspaces on the Perforce server. To save the server resources, you can clean inactive workspaces created by TeamCity directly from the TeamCity UI.
Running Personal Builds from IntelliJ IDE
If you write code in an IntelliJ-based IDE, you can pretest and prebuild local changes before committing them to a main Perforce repository: see common instructions on remote run, remote debug, and pre-test delayed commits.
The remote run/debug functionality is common for all types of VCS, but there are extra conveniences specific to Perforce:
Running Builds on Perforce Shelved Files
TeamCity allows you to run personal builds on Perforce shelved files. This way, you can try building changed source files before checking them into a common depot.
To manually run a custom build on Perforce shelved files:
Open the custom run dialog by clicking the context menu next to the Run button.
Enable run as a personal build option.
Enter the ID of the changelist that contains the shelved files.
Choose the target Perforce root.
To configure automatic triggering for a Perforce shelved changelist:
Go to Build Configuration Settings | Triggers.
Add a new trigger of the Perforce Shelve Trigger type.
Configure its settings as described in this article.
Publishing Build Statuses to Perforce Helix Swarm
If you use Perforce Helix Swarm for code review of shelved files, you can configure TeamCity to posts build statuses as comments to your reviews:
Go to Build Configuration Settings | Build Features.
Add a new feature of the Commit Status Publisher type.
Choose Perforce Helix Swarm as the feature type.
Enter the settings:
Your Helix Swarm server's URL.
A username and cross-host ticket for connection (use the
p4 login -a -pcommand to obtain one).
After this feature is configured, TeamCity will be publishing the build statuses' updates as comments to the respective code reviews in Helix Swarm:
Note that Helix Swarm usually creates reviews on shelved changelists whose description contains a special keyword, depending on your setup (for example,
#review). If you want TeamCity to trigger builds on Perforce shelved files automatically, you need to specify the same keyword in the Perforce Shelve Trigger settings as well.
TeamCity Workspaces in Perforce
To perform Perforce-related operations, a TeamCity server usually executes Perforce commands without the workspace context. For instance, workspaces are not required for tracking changes and for most server-side operations. However, certain cases require creating a dedicated workspace:
By default, TeamCity uses agent-side checkout mode for checking out sources of a build. In this case, it creates a dedicated Perforce workspace and executes a corresponding
p4 synccommand to get the sources.
Using a Perforce VCS root to store versioned project settings.
Using Perforce streams as feature branches. In this case, TeamCity creates workspaces on the Perforce server to correctly process task streams.
Learn how TeamCity creates workspaces in Perforce and works with them in this article.
Configuring Post-Commit Hooks on Perforce Server
By default, TeamCity uses a polling approach to detect changes in a VCS repository. It periodically sends requests to the Perforce server to detect new revisions. For large installations with hundreds of VCS roots, this may create a noticeable load on both Perforce server and TeamCity. To avoid background polling, you can set up a post-commit hook on your Perforce server. This hook will notify TeamCity to start checking for changes only when they are available.
TeamCity provides a dedicated hook script that should be saved on your Perforce server. You can find the detailed instruction here.
Label Perforce Sources
TeamCity can assign custom labels to Perforce project sources. The list of applied labels and their status is displayed on the Changes tab of Build Results.
To configure automatic labeling for a build configuration:
Go to Build Configuration Settings | Build Features.
Add a new feature of the VCS labeling type.
Choose a Perforce VCS root to label.
Specify the labeling pattern as described here.
View Perforce Jobs
If a build contains a changelist that is associated with one or more jobs, TeamCity will show a wrench icon next to this change in the build results. Click or hover it to view the details of the relevant jobs.
View Perforce Logs
All operations of the Perforce plugin are logged in to the
teamcity-vcs.log files with the category
jetbrains.buildServer.VCS.P4 (on an agent or on a server, depending on the operation mode). The detailed logging can be enabled with TeamCity Server Logs.