Pull Requests
The Pull Requests build feature lets you automatically load pull request* information and run builds on pull request branches in GitHub, Bitbucket Server, Bitbucket Cloud, GitLab, Azure DevOps, and JetBrains Space.
* Or merge requests in case of GitLab and JetBrains Space.
When adding this build feature, you need to specify a VCS root and select a VCS hosting type.
Other settings depend on the selected VCS hosting type.
This feature extends the original branch specification of VCS roots, attached to the current build configuration, to include pull requests that match the specified filtering criteria.
You can find the pull request's details displayed on the Overview tab of the Build Results:
![Pull request details Pull request details](https://resources.jetbrains.com/help/img/teamcity/2023.09/pr-info.png)
If you configure a VCS trigger for your build configuration, TeamCity will automatically run builds on changes detected in the monitored branches. For example, to auto-start building pull requests for GitHub repositories, add a new trigger (or modify the existing one) with the +:pull/*
branch filter rule.
See the example on how to set up TeamCity to run builds on GitHub pull requests, or watch our video tutorial.
VCS-specific settings
GitHub Pull Requests
This feature supports GitHub and GitHub Enterprise. It monitors builds only on the refs/pull/*/head
branch.
The following parameters are available for the GitHub hosting type:
Parameter | Option | Description |
---|---|---|
Authentication Type | Use VCS root credentials | TeamCity will try to extract username/password credentials or a personal access token/ This option will not work if the VCS root employs anonymous authentication or SSH. For a GitHub Enterprise repository, only the personal access token/ |
Access token | Use a personal access token or obtain a token through an OAuth connection. It must have either the | |
GitHub App access token | A non-personal short-lived token issued via the GitHub App. This option is available only when the VCS Root setting points to the specific VCS root, and this root is configured using a GitHub App connection. | |
By authors The filter applies to public repositories only. | Members of the same organization | Only detects pull requests submitted by members of the same organization in GitHub. |
Members and external collaborators | Only detects pull requests submitted by members of the same organization and external collaborators in GitHub. | |
Everybody | Detects all pull requests. Be aware that selecting this option may allow arbitrary users to execute malicious code on your build agents. | |
By source branch | Define the branch filter to monitor pull requests only on source branches that match the specified criteria. If left empty, no filters apply. | |
By target branch | Define the branch filter to monitor pull requests only on target branches that match the specified criteria. If left empty, no filters apply. | |
Ignore Drafts | By default, the Pull Requests build feature loads the GitHub draft pull requests information and runs builds on draft pull requests. The build page displays the "Draft" status and icon next to the pull request number. Check the box to ignore GitHub draft pull requests. TeamCity will not load the draft pull request information until its status changes. | |
Server URL | Specify a GitHub URL for connection. If left empty, the URL will be extracted from the VCS root fetch URL. |
Bitbucket Server Pull Requests
The following parameters are available for the Bitbucket Server hosting type:
Parameter | Options | Description |
---|---|---|
Authentication Type | Use VCS root credentials | TeamCity will try to extract username/password credentials from the VCS root settings if the VCS root uses HTTP(S) fetch URL. This option will not work if the VCS root employs anonymous authentication. |
Username/password | Specify a username and password for connection to Bitbucket Server. You can submit an access token instead of the password. The token should have Read permissions for projects and repositories. | |
By source branch | Define the branch filter to monitor pull requests only on source branches that match the specified criteria. If left empty, no filters apply. | |
By target branch | Define the branch filter to monitor pull requests only on target branches that match the specified criteria. If left empty, no filters apply. | |
Server URL | Specify a Bitbucket URL for connection. If left empty, the URL will be extracted from the VCS root fetch URL. | |
Use pull request branches | This option is intended for backward compatibility only. Enables detection of officially unsupported Bitbucket pull request branches (pull-requests/*) instead of source branches. Be careful: new builds might be triggered for changes committed within the last hour after switching. |
Bitbucket Cloud Pull Requests
Since Bitbucket Cloud does not create dedicated branches for pull requests, this build feature monitors directly source branches in a source repository (forks are not supported).
If more than one pull request is submitted from the same source branch at the moment of the build start, TeamCity will display all these requests in the build results. However, only commits from the open PRs matching the filtering criteria will be displayed as Changes of the build.
Note that the branch specification of the VCS root must not contain patterns matching pull request branches.
The following parameters are available for the Bitbucket Cloud hosting type:
Setting | Description |
---|---|
Authentication Type |
|
By target branch | Define the branch filter to monitor pull requests only on branches that match the specified criteria. If left empty, no filters apply. |
GitLab Merge Requests
TeamCity processes GitLab merge requests similarly to how it processes pull requests in other hosting services. Currently, TeamCity detects only merge requests submitted after this build feature is enabled.
This feature monitors builds only on the refs/merge-requests/*/head
branch.
The following parameters are available for the GitLab hosting type:
Parameter | Description |
---|---|
Authentication Type |
|
By source branch | Define the branch filter to monitor merge requests only on source branches that match the specified criteria. If left empty, no filters apply. |
By target branch | Define the branch filter to monitor merge requests only on target branches that match the specified criteria. If left empty, no filters apply. |
Server URL | Specify a GitLab URL for connection. If left empty, the URL will be extracted from the VCS root fetch URL. |
Azure DevOps Pull Requests
This feature monitors builds only on the refs/pull/*/merge
branch.
In case with Azure DevOps, TeamCity detects requests on a merge branch — not on the pull request itself as with other VCSs. Each build will be launched on a virtual branch showing an actual result of the build after merging the PR. Thus, the build will contain both the commit with changes and the virtual merge commit.
Note that the feature ignores Azure DevOps draft pull requests.
The following parameters are available for the Azure DevOps hosting type:
Parameter | Description |
---|---|
Access token | Use a personal access token for connection. The token must have the |
By source branch | Define the branch filter to monitor pull requests only on source branches that match the specified criteria. If left empty, no filters apply. |
By target branch | Define the branch filter to monitor pull requests only on target branches that match the specified criteria. If left empty, no filters apply. |
Project URL | Specify a project URL for synchronization with the remote Azure DevOps server. This field is recommended for on-premises Azure DevOps installations. If left empty, the URL will be composed based on the VCS root fetch URL. |
JetBrains Space Merge Requests
This feature monitors merge requests directly in the source branches of an origin repository.
If more than one merge request is submitted from the same source branch, TeamCity will display all these requests in the build results. However, only commits from the open requests matching the filtering criteria will be displayed as Changes of the build.
The following parameters are available for the JetBrains Space hosting type:
Parameter | Description |
---|---|
Connection | Choose a preconfigured connection to JetBrains Space. |
By target branch | Define the branch filter to monitor merge requests only on branches that match the specified criteria. If left empty, no filters apply. |
If you want to run several parallel builds to pretest a request before merging it, the best solution is to:
Create a composite build configuration and attach your JetBrains Space VCS root with an empty branch specification to it.
Add the composite build configuration at the end of the build chain by configuring its snapshot dependencies on parallel builds with tests.
Add the Pull Requests feature to each build configuration of the chain so that all builds can detect changes in a merge request branch. You can preconfigure all settings in a build configuration template and then create these build configurations based on it.
In the composite build configuration settings:
Add a VCS trigger to automatically run builds on changes detected in the merge request branch.
Add the Commit Status Publisher feature to send the build statuses to the commit details in JetBrains Space.
If you want other builds of the chain to report their statuses to JetBrains Space (for example, deployment or integration testing builds), add the Commit Status Publisher feature to the corresponding build configurations.
After that, TeamCity will automatically run builds on changes in a merge request branch submitted to your JetBrains Space repo and publish build statuses to the merge request timeline in Space:
![Space merge request timeline Space merge request timeline](https://resources.jetbrains.com/help/img/teamcity/2023.09/space-timeline.png)
To protect a JetBrains Space branch from unverified merge requests, you can also configure Quality Gates in your repository settings. If you set a TeamCity build as an external check, JetBrains Space will require the build on a merge request to finish successfully before allowing this request to be merged.
See known issues with processing JetBrains Space merge requests here.
Predefined build parameters for pull requests
TeamCity provides multiple predefined build parameters that expose valuable information on pull requests for builds with the enabled Pull Requests feature:
You can use these parameters in the settings of a build configuration or in build scripts.
Pull Requests workflow example
Let's say you have the following environment set up:
Public GitHub repository
web-app
with the default branchmaster
.TeamCity project.
Build configuration
web-app
that uses files from theweb-app
repository to build a web application.
The members of your organization propose changes to the sources by sending pull requests to the master
branch, and you want these changes to be automatically built and tested in TeamCity before you merge them.
TeamCity can detect each pull request sent to the master
branch and build the web application based on the updated sources.
To configure the described workflow for the web-app
build configuration in TeamCity:
Add a VCS root to the build configuration:
Go to Build Configuration Settings | Version Control Settings and click Attach VCS root.
Configure the root parameters:
Type of VCS: Git
VCS root name: <unique_root_name>
Fetch URL: <GitHub_repository_URL>
Default branch: the branch to be monitored; by default,
refs/heads/master
(read more about feature branches)Branch specification: a filter for additional branches to be monitored (for example,
+:refs/heads/*
)Authentication parameters of the GitHub user that has access rights to the
web-app
repository
Test the connection and, if successful, click Create.
Add the Pull Requests build feature to the build configuration:
Go to Build Configuration Settings | Build Features and click Add build feature.
Configure the feature parameters:
VCS Root: the VCS root created at Step 1
VCS hosting type: GitHub
Authentication type: Use VCS root credentials, or select Access token to use a GitHub token instead
Pull Requests filtering:
By authors: Members of the same organization
By target branch: leave empty to apply no filters and monitor all new pull requests in the repository, or explicitly specify the target branch (in this example,
master
)
Test the connection and, if successful, click Save.
Add a VCS trigger to the build configuration.
That's it! Now, whenever a member of your GitHub organization sends a pull request to the master
branch, TeamCity acts as follows:
Detects the pull request sent to the
master
branch.Runs the
web-app
build configuration: collects sources, builds and tests the app according to your predefined build steps.Displays information about the processed pull request on the build configuration Overview page. You can instantly see the pull request status (1) and refresh the information about its state (2).
Pro Tips
You can automate your setup further, so TeamCity:
Sends a build status back to GitHub after the build finishes, with the Commit Status Publisher build feature.
Merges the pull request in GitHub if the build finishes successfully, with the Automatic Merge build feature.
If you want to run a whole build chain on a pull request, remember to add the Pull Requests feature to each build configuration of the chain. To simplify this procedure, you can set everything in a build configuration template and then create these build configurations based on it.