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.

About Anton Arhipov

Developer Advocate at JetBrains
This entry was posted in Blogroll, Features, FYI and tagged , , , . Bookmark the permalink.

24 Responses to GitHub Pull Requests plugin for TeamCity

  1. Juan says:

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

  2. Michael says:

    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?

  3. jonnii says:

    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…

    • Anton Zamolotskikh says:

      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!

  4. Jan says:

    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.

    • Anton Arhipov says:

      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?

    • Anton Zamolotskikh says:

      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. Philippe Gref-Viau says:

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

  6. Alex Zabrodskiy says:

    No docs is ok for JB i see

  7. Nahuel says:

    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.

    • Anton Zamolotskikh says:

      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. Nikolaj says:

    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.
    Before:
    [TeamCity, FAILED] Build Builds / Core [niko/do-this-and-that] #1234
    After:
    [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.

Leave a Reply to Pavel Sher Cancel reply

Your email address will not be published. Required fields are marked *