The plugin is not build for serving pull request, as there are many pull request builders. You might be able to create a refspec to match pull request, and make it work though.
Our git flow is designed so your just push your changes to a "ready" branch, and the plugin sees this and run the integration (if build steps succeeds).
So let me suggest a simpler flow:
master: do not touch (normally master is integration, but you can use another)
story/**: your feature branches while developing on them, exist locally in developer clone or the corporate repo for backup
integration: where you share work with you colleagues - it must be verified with pretested plugin first
maintenance: ... you can have those also
So when I'm done with my story/plugin-25872 I push it to a "ready" branch
git push origin story/plugin-25872:ready/plugin-25872
and my jenkins verify jobs start. If successful it merges ready/plugin-25872 into to "integration" branch. No need for pull requests.
You can use Accummulated strategy, or the squashed strategy. Explained in details here: http://www.josra.org/blog/Pretested+integration+plugin.html
If you would do this setup, you need:
- one git repository configured in your job, explicitly name it 'origin'
- git scm -> branch specifier: origin/ready/**
- pretested integration plugin -> integration branch: integration
- integration branch should already exist in the origin repo
This way, whenever someone pushed to a ready-branch, the job starts and run your build steps and integrate changes if successful. Typically build steps like compile, compile unit-test, run unit-test are good criterias for sharing code.
At some point later in your continuous delivery pipeline you will merge from integration branch to master, maybe after functional testing.
The pretested integration plugin is made to automate our git flow: http://www.praqma.com/resources/papers/git-flow
You still need to be able to run git command command line on your build slave, as the plugin does not work with other credentials in all cases.