Blogroll Features FYI

GitHub Pull Requests plugin for TeamCity

The hassle with Pull Requests

These days pull requests is a common technique of accepting changes from third-party contributors. In fact, it proved to be so convenient that some companies started to use it even for their regular development workflows.

It is possible to configure TeamCity to run builds on GitHub pull request branches. One had to provide a VCS root branch specification like refs/pull/*/head for that. However, this configuration is not without its downsides.

For instance, with this configuration, the pull request for TeamCity is just a branch in a Git repository. It means that it is impossible to distinguish pull requests by their target branches. Moreover, it is a known fact that even if a pull request is closed in GitHub, the corresponding branch remains in a Git repository. It is not so uncommon to see repositories with several thousands of pull request-related branches. In TeamCity they clutter the user interface and make the performance worse.

TeamCity does not know who opened the pull request either, so it is not possible to limit the builds of pull requests opened by the organization members only. As a result, if third parties can open pull requests for your repositories, configuring TeamCity to build pull requests imposes a big security risk.

GitHub Pull Requests plugin

The new GitHub Pull Requests plugin is intended to address all the issues described above. As stated in the plugin name, it supports GitHub and GitHub Enterprise only.

The plugin provides a build feature which allows filtering pull requests that you want to build:

The author filter in the build feature configuration settings provides the following options:

  • PRs coming from the members of the same organization only
  • PRs from the members and all external collaborators
  • PRs from everybody.

Once the new build feature is added to a build configuration, TeamCity will provide additional details for the pull request branch on the build overview page:

The plugin is compatible with TeamCity 2018.1.x. You can download it from the plugin repository.

As usual, we will be happy to get your feedback! Our forum and tracker are at your disposal and if you encounter any problems, please share them with us to help us improve.

Comments below can no longer be edited.

26 Responses to GitHub Pull Requests plugin for TeamCity

  1. Avatar

    Juan says:

    October 8, 2018

    Is it going to be available for IntelliJIdea IDE? And Android Studio

  2. Avatar

    Michael says:

    October 9, 2018

    This sounds great. Is it possible to create a fork of this plugin for BitBucket? Or possibly even a PR to add support as a third option?

    • Avatar

      Pavel Sher says:

      October 9, 2018

      Bitbucket server or Bitbucket cloud?

      • Avatar

        Ken says:

        November 20, 2018

        Bitbucket Cloud, please! (Sorry Michael, I hijacked your request. Hopefully BBCloud is what you want, too.)

        • Avatar

          Sergey says:

          December 10, 2018


      • Avatar

        Denis Khomich says:

        December 7, 2018

        BitBucket Server!

        • Avatar

          Daniel says:

          January 7, 2019

          +1 for Server

        • Avatar

          Joseph says:

          February 26, 2019

          +1 for Server

  3. Avatar

    jonnii says:

    October 10, 2018

    What does this build exactly? You can configure teamcity to build either the tip of the pull request branch or the merged commit. In the case of the latter it gives you more confidence that when merged your build will be successful. In the above example it looks like it’s building the branch…

    • Avatar

      Anton Zamolotskikh says:

      October 11, 2018

      Hi jonnii, the plugin indeed builds pull request branches themselves, not the pre-fly merge branches by default and does not provide a way to choose otherwise.

      However there is an experimental feature that provides such an option. If you set a TeamCity internal property teamcity.pullRequests.buildBranchFilterEnabled to true, the GitHub Pull Requests build feature settings dialog will contain one more field “By PR branches”, which will allow you to choose if you want to build head branches, merge branches or both.

      Please be aware that the feature is experimental and may cause some unexpected effects (e.g. extra builds, builds failing without reason) in builds of the merge branches. If you are going to use it, please provide us with you feedback. Thanks!

      • Avatar

        Richard Lavey says:

        January 22, 2019

        I’ve enabled the property (TC 2018.2.1) but setting the PR Branches to “both” only builds the pull/X branch, not the X/merge one when a commit is pushed to the PR branch.

        Setting to “pre-fly merge branches only” doesn’t trigger builds on PR branch commit.

        • Avatar

          Anton Zamolotskikh says:

          January 22, 2019

          Hi Richard, this is quite piculiar.

          Would you be so kind to log an issue in our issue tracker please, providing relevant build feature, build trigger and VCS root configuration information, as well as relevant fragments of teamcity-server.log?


  4. Avatar

    Jan says:

    October 18, 2018

    This still doesn’t fix the issue in my case. Let’s say I have a pipeline “build > test > deploy”. Scenario: User creates a pull request on Github for branch feature-123, this action triggers build and test on logical branch “1234”. If the user would like to run “deploy” and reuse, same build and test jobs which already successfully completed he has to search for 1234 branch instead of feature-123. This is a terrible user experience. Because of this, I don’t use TC built-in support for GH PRs instead, I created my own GH webhook handler which triggers jobs with human readable branch names.

    • Avatar

      Anton Arhipov says:

      October 22, 2018

      Hello Jan! Thanks for sharing your concern!

      It seems to me that your use case doesn’t relate to the subject of the blog post though. Would you mind submitting the issue to our issue tracker with this description?

    • Avatar

      Anton Zamolotskikh says:

      November 13, 2018

      Hi Jan,
      Did I get it right that you are describing a situation when users manually run that “deploy” builds? Do you think a separate “Pull requests” tab on the build configuration details page, that would contain more detailed information about each pull request including its title, author, status, etc, and would allow to start builds, would resolve this confusion?

  5. Avatar

    Philippe Gref-Viau says:

    November 20, 2018

    Any plans to expose the same functionality for GitLab merge-requests?

    • Avatar

      Anton Zamolotskikh says:

      November 20, 2018

      Yes, we are planning to do so at some point after 2018.2 is released.

  6. Avatar

    Alex Zabrodskiy says:

    December 14, 2018

    No docs is ok for JB i see

  7. Avatar

    Nahuel says:

    December 18, 2018

    What the VCS trigger should looks like? B/c after adding this build feature, it’s not triggering the build even if the VCS trigger admits all possible branches.

    • Avatar

      Anton Zamolotskikh says:

      December 18, 2018

      Hi Nahuel,

      Would you mind to provide more details, i.e.:
      – have you tried to use Test Connection button in the build feature, does it report success?
      – do you observe any errors on the build configuration overview page?
      – if you have any commits in the default branch, do any builds trigger on these?
      – what is the branch filter value on your VCS trigger?
      – could it be the case, that the settings of the build feature are set in a such way, to filter out all your pull requests? It could happen for example if you use default settings and all your pull requests are coming from contributors outside your organisation (in GitHub terms).

  8. Avatar

    Nikolaj says:

    January 16, 2019

    Is there any way to make build failure notification clearer? We’ve recently switched from building all the branches to building PRs only, and build failure notifications suddenly became cryptic.
    [TeamCity, FAILED] Build Builds / Core [niko/do-this-and-that] #1234
    [TeamCity, FAILED] Build Builds / Core [pull/666] #2345

    Due to branch names being (usually) descriptive, I could decide on whether it’s of my concern or not (e.g., somebody has merged my changes into their own pre-broken branch). Now I have to either remember my PR numbers, scan through list of changes or open the PR link, neither of which is a good option.

  9. Avatar

    Maksym Grebenets says:

    April 2, 2019

    Nice plugin, but for me didn’t work because it takes over VCS root branch specification completely.
    Actually, it’s not mentioned anywhere in documentation, when using this plugin the VCS root branch specification must be empty, so that plugin can take it over.

    Otherwise plugin doesn’t work and doesn’t show any warning.
    Even if I have proper branch spec for PRs declared.

    What I want from the plugin, is its ability to hide PRs which are no longer open, but allow me to control branch spec nonetheless.

    For example, I have a CI job which I want to run for master, release/*, poc/* and pull/*/head.
    This is on purpose. The CI job is just a “check” which I want to run for different branches and not only for PRs.

    The plugin, however, will only allow we to have default branch (e.g. refs/heads/master) and pull request branches, removing all other branches like release/*.

    So to sum it up, it would be nice if plugin would allow me to use my own branch specifications as long as I have pull/*/head specified.
    (and some warnings when plugin doesn’t work due to misconfiguration wouldn’t hurt, or more details documentation on VCS config)

    • Avatar

      Anton Zamolotskikh says:

      April 2, 2019

      Hi Maksym,

      What you are describing doesn’t look like an expected behaviour. The plugin extends the branch spec, but doesn’t replace it. Basically you don’t have to have a branch spec of refs/pull/*/head configured for the plugin to work (and if you do, all PR branches will be used, not only ones filtered by the plugin), but any other branch specs should be just fine. So in your case it could be a bug in the plugin or a case of misconfiguration.

      Would you mind to create an issue on our issue tracker here: and provide exact desribtion of it, i.e. a default branch, exact branch specs, your triggers configuration including the branch filter in it (if any), the configuration of the pull requests build feature, what you percieve as “not working” (not detecting changes, not triggering builds?) and anything else you consider relevant. Thanks!

Discover more