search

janinko / ghprb

github pull requests builder plugin for Jenkins
https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
MIT License
370 stars 20 forks source link

readme

NOTE: this plugin is currently maintained at https://github.com/jenkinsci/ghprb-plugin

GitHub Pull Request Builder Plugin

This Jenkins plugin builds pull requests from GitHub and will report the results directly to the pull request via the GitHub Commit Status API

When a new pull request is opened in the project and the author of the pull request isn't whitelisted, builder will ask Can one of the admins verify this patch?. One of the admins can comment ok to test to accept this pull request for testing, test this please for one time test run and add to whitelist to add the author to the whitelist.

If an author of a pull request is whitelisted, adding a new pull request or new commit to an existing pull request will start a new build.

A new build can also be started with a comment: retest this please.

You can extend the standard build comment message on GitHub creating a comment file from shell console or any other jenkins plugin. Contents of that file will be added to the comment on GitHub. This is useful for posting some build dependent urls for users without access to the jenkins UI console.

Jobs can be configured to only build if a matching comment is added to a pull request. For instance, if you have two job you want to run against a pull request, a smoke test job and a full test job, you can configure the full test job to only run if someone adds the comment full test please on the pull request.

For more details, see https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin

Master status:

Build Status

Required Jenkins Plugins:

Pre-installation:

Installation:

Credentials

Creating a job:

Make sure you DON'T have Prune remote branches before build advanced option selected, since it will prune the branch created to test this build.

Parameterized Builds

If you want to manually build the job, in the job setting check This build is parameterized and add string parameter named sha1 with a default value of master. When starting build give the sha1 parameter commit id you want to build or refname (eg: origin/pr/9/head).

Job DSL Support

Since the plugin contains an extension for the Job DSL plugin to add DSL syntax for configuring the build trigger and the pull request merger post-build action.

It is also possible to set Downstream job commit statuses when displayBuildErrorsOnDownstreamBuilds() is set in the upstream job's triggers and downstreamCommitStatus block is included in the downstream job's wrappers.

Here is an example showing all DSL syntax elements:

job('upstreamJob') {
    scm {
        git {
            remote {
                github('test-owner/test-project')
                refspec('+refs/pull/*:refs/remotes/origin/pr/*')
            }
            branch('${sha1}')
        }
    }

    triggers {
        pullRequest {
            admin('user_1')
            admins(['user_2', 'user_3'])
            userWhitelist('you@you.com')
            userWhitelist(['me@me.com', 'they@they.com'])
            orgWhitelist('my_github_org')
            orgWhitelist(['your_github_org', 'another_org'])
            cron('H/5 * * * *')
            triggerPhrase('OK to test')
            onlyTriggerPhrase()
            useGitHubHooks()
            permitAll()
            autoCloseFailedPullRequests()
            displayBuildErrorsOnDownstreamBuilds()
            whiteListTargetBranches(['master','test', 'test2'])
            allowMembersOfWhitelistedOrgsAsAdmin()
            extensions {
                commitStatus {
                    context('deploy to staging site')
                    triggeredStatus('starting deployment to staging site...')
                    startedStatus('deploying to staging site...')
                    addTestResults(true)
                    statusUrl('http://mystatussite.com/prs')
                    completedStatus('SUCCESS', 'All is well')
                    completedStatus('FAILURE', 'Something went wrong. Investigate!')
                    completedStatus('PENDING', 'still in progress...')
                    completedStatus('ERROR', 'Something went really wrong. Investigate!')
                }
            }
        }
    }
    publishers {
        mergeGithubPullRequest {
            mergeComment('merged by Jenkins')
            onlyAdminsMerge()
            disallowOwnCode()
            failOnNonMerge()
            deleteOnMerge()
        }
    }
}

job('downstreamJob') {
    wrappers {
        downstreamCommitStatus {
            context('CONTEXT NAME')
            triggeredStatus("The job has triggered")
            startedStatus("The job has started")
            statusUrl()
            completedStatus('SUCCESS', "The job has passed")
            completedStatus('FAILURE', "The job has failed")
            completedStatus('ERROR', "The job has resulted in an error")
        }
    }
}

Updates

-> 1.30.2

-> 1.30.1

-> 1.30

-> 1.29.8

-> 1.29.7

-> 1.29.5

-> 1.29.4

-> 1.29.1

-> 1.29

-> 1.28

-> 1.27

-> 1.26

-> 1.25

-> 1.24.x

-> 1.24

-> 1.23 - 1.23.2

-> 1.22.x

-> 1.22

-> 1.21

-> 1.20.1

-> 1.20

-> 1.19

-> 1.18

-> 1.14

-> 1.13-1

-> 1.8

In version 1.8 the GitHub hook url changed from http://yourserver.com/jenkins/job/JOBNAME/ghprbhook to http://yourserver.com/jenkins/ghprbhook/. This shouldn't be noticeable in most cases but you can have two webhooks configured in you repository.

-> 1.4

When updating to versions 1.4 phrases for retesting on existing pull requsts can stop working. The solution is comment in pull request with ok to test or remove and create the job. This is caused because there was change in phrases.