This is how you easily build and deploy from GitHub pull requests

elasticbox-jenkins-logo

We last showed how ElasticBox works with Jenkins to run workloads on remote machines in any cloud, any pre-defined slave build environment. This time, we make it easy to handle GitHub pull requests. The ElasticBox Jenkins plugin directly manages the GitHub pull request lifecycle. So what does that mean to you?

Handle GitHub pull requests with ease

First, you’ll be glad to know that the plugin configures Git by default so that Git checks out the source from the pull request for the build. The default setting works for any public repository. For a private repository, provide the credential to connect via SSH or change the repository URL in the Git section of the job.

Jenkins-blog-post-Jan2015

Second, the plugin triggers job builds based on certain pull request events. It triggers when you create a new pull request, push a new commit to an existing pull request, post a comment with the trigger phrase defined in the job, or reopen a closed pull request.

Third, and most importantly, the plugin conserves infrastructure and build slave resources. After your pull requests merge or close, it automatically terminates and deletes instances that Jenkins launches through ElasticBox build steps. These are instances allocated to the build job. Such cleanup normally require you to set up additional build steps or jobs, which sometimes fail when the Jenkins server crashes or restarts.

What’s next?

Want to get started with the GitHub pull request lifecycle manager? Download or update version 0.9.8 of the ElasticBox Jenkins plugin. Make ElasticBox part of your Jenkins jobs and fully automate your CI/CD dream. It’s simply a matter of clicking a checkbox.

Hacker News

Categories: Cloud Application Management, Cool Features & Tutorials, ElasticBox, Jenkins
Tags: , , , , , , ,