BuildHive: Build GitHub Projects in Cloud-enabled Community Jenkins

If you are short on time - go see it in action. For the rest:

If you know CloudBees, you know that we are passionate about continuous integration (CI). We have been responsible for expanding the definition of PaaS in the market to encompass continuous integration. However, if truth be spoken, we have been a bit of the bad guys. We have pushed open source projects to face up to the status quo and make decisions.

Let me explain: Open source projects thrive on interactions based around the code. Any code that makes it into the repository has to be built and tested. Today, committers push their code, and an on-premises Jenkins builds a job. The project administrators usually setup a public facing Jenkins instance to show whats happening (see example). However, for resource poor projects or fledgling OSS projects - it is years before they get to this world. So many projects just skip this step.

This is where we stepped in and made it extremely easy to host projects on CloudBees DEV@cloud and have a program for FOSS projects to host their projects on us free. This meant that we took away any excuse for administrators to not have CI. In the process, we ended becoming this nagging voice in a community member's head asking them to setup CI for their projects.

Who likes to be a nagger or the bad guys? Definitely not us!

Everthing has to be easy if not easier…

So over the last few months we have worked to silence (in a good way) that nagging voice in a community member's head.

Today, we launch BuildHive - BuildHive is Jenkins for the community and works with projects hosted on GitHub. Administrators login to GitHub, one-click enable their projects for BuildHive. BuildHive sniffs multiple project types - today Ant, Maven, Gradle, sbt (Scala) and Rake (Ruby) - and automatically sets up a corresponding build. In the majority of the projects, users will end up with absolutely no configuration changes for their projects.

Every time there is a commit in the project, BuildHive will build the project and the status will be shown on the community dashboard. Administrators no longer have to figure out how (and where?) to setup their on-premises Jenkins or put in work to expose it to their community.

Apart from the obvious benefit of easily CI-enabling jobs on GitHub and consequently improving the project health - BuildHive will fundamentally move the starting conversation in OSS contributions from source to builds. Today, project owners get pull requests from contributors with an email indicating that the code built successfully. The owner still ends up pulling in the code, merging it in and building the code. If the code does not build - administrators work with contributors to fix these issues. This is one significant investment for an administrator (multiplied by 10s-100s pull requests for a project). With BuildHive in place, the onus moves from the administrator/contributor to BuildHive. BuildHive automatically merges a pull request and builds it - so now a pull request is accompanied by the build status. If the build failed, the administrator does not have to entertain the request - saving them hours and perhaps giving them a nice weekend in the process :-).

BuildHive has used our investments in our Jenkins-in-the-cloud product (DEV@cloud) and the Templates plugin within our on-premises offering called Jenkins Enterprise. As an administrator, if you need more cloud resources like executors, and complete Jenkins configurability - GitHub projects can use DEV@cloud.

Honestly, it was more work explaining it than actually using it. Lets just get rolling and see it in action.

- Harpreet Singh

Senior Director, Product Management
CloudBees
cloudbees.com