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.

13 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?

Leave a Reply

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