BuildHive is a free service that lets you set up Jenkins-based continuous integration build/test jobs for your GitHub repositories with just a few mouse clicks. It is freely available for anyone to use.
The top page shows recent builds that have happened on BuildHive. If you keep the page open for a while, you'll see new cards appear from the left for new builds in semi-real time:
Let's click the big red "Add your Git repositories" button to set up CI jobs for your repositories. It'll first ask you to approve GitHub OAuth integration, so you need to click "Allow" to let us see your repositories and install hooks:
Once logged in, you'll see the screen to select repositories from GitHub. It will show all your personal repositories as well as repositories from any organizations that you belong to. If you have too many repositories, use the filter text box to narrow down the candidates.
All you have to do to set up a CI job is to click "Enable". We'll sniff your repository to guess the initial build configuration. The auto sniffing of the repository contents is extensible, but the initial set is geared toward Java projects (like Ant, Maven, Gradle), but also covers some Ruby projects as well.
In any case, auto-sniffing can only do so much. You can tweak the setting via the configuration screen (for example, to update where the notification e-mails are sent):
When you enable a repository, we auto-install necessary hooks for you, so that it'll build your project every time someone pushes to your repository. In addition to that, we'll speculatively build incoming pull requests to your repository (by building the result of the merge between the incoming commit and the current tip of the branch for which the pull request is sent), and report the status as a comment to the pull request:
So you can use that as one of the inputs to determine if you are going to merge a pull request or not.
Behind the scene, many of the features in BuildHive rely on our value-add plugins for Jenkins Enterprise by CloudBees, which are available for customers to use on their own Jenkins instances. For example, we use the Templates plugin to model various project types and for auto-sniffing. We use the Validated Merge plugin to speculatively build pull requests. So, while it isn't as easy as it could be, our customers can set up a similar environment in their own Jenkins instance, or they can re-use those pieces to create similar but different workflows.
And needless to say, there are many other open-source plugins at play, too — it really shows off the power of extensibility in Jenkins.