Automated Pull Requests

Approving/Rejecting pull requests with automated builds

Project logistics

  • Mentors:
    • Sam Howes Email:
  • Min-max team size: 3-5
  • Expected project hours per week (per team member): 6-8
  • Open source

Preferred past experience

  • Java
  • Git (Nice to have)
  • Automated Testing (Nice to have)
  • Build Automation (Nice to have)

Project Overview


The goal of this project is to eliminate the human step required in ensuring pull requests contain quality code, and have a Build Server do building and testing of pull requests. The build server (TeamCity) will then interact with the repository host and approve or reject the pull request based on the build results. This will prevent broken code from being pushed into the main branch, and ruining the team's productivity.


Pull requests are an important piece of the development process. When a developer has finished work on a particular feature, they create a pull request to merge that feature into the main source control branch. This pull request is then reviewed by the developer's teammatea who provide feedback on the code. When they approve the Pull Request, it is merged into the main branch of the codebase, and available for the rest of the team to code against.

In a perfect world, before submitting the pull request, the devloper builds the entire project, and makes sure all of the automated tests pass successfully. In a perfect world, the devloper that is reviewing the pull request pulls down the source branch to their local repository, builds the code and runs all the tests as well. In practice, both of these steps rarely followed for all the code in the codebase.

For example, when you are developing a web application, a database must be built and deployed, then the web-application has to be launched and smoke tested - because some errors only happen at run-time, not compile-time. This process can take up to 15 minutes. To save time, developers will skip this build and testing step and complete the pull request. If someone missed something, the build could break, and everyone's work is interrupted because they can't develop against broken code. In many teams, this will earn you a token of appreciation for interrupting everyone's work:

Some Technologies you will learn/use:

  • TeamCity build server
  • Java to write a TeamCity Plugin
  • Visual Studio Team Services repository hosting and work item tracking.
    • Rest api docs
    • *Note: Visual Studio Online has been re-branded as Visual Studio Team Services recently. It is a work item tracking system similar to JIRA, it is not to be confused with the Visual Studio IDE used for writing code.
  • Additional hosting providers: GitHub, BitBucket, others?