I'm attempting to set up the Jenkins PR builder plugin to hit github on new pull request. I've followed along with the docs, and have tried "many" different configurations, but I can't seem to get past this:
"Ignoring refs/heads/jenkins_testing as it doesn't match any of the configured refspecs"
If I leave the branch specifier empty, "any" change on a PR does fire a build. From this, I know
Refspec : I'm using the prescribed settings for PRs only -
+refs/pull/*:refs/remotes/origin/pr/*
Branches I've tried a number of settings
${sha1} - ignored
${ghprbActualCommit} - ignored
branch-id - gets built, but I need "any" PR
** (blank) - too much gets built, undesirable
Jenkins / PR builder config :
Results of polling persist:
I am aware of this bug that causes exactly this issue, but after updating from 1.31 to 1.33, the issue persists.
I have read about running two processes, but I'm not sure why I'd need that (please explain, if that would have ).
Can you see anything wrong in my config? Any clarification or advice would be most welcome.
Cheers -
It appears, based on the refspec of +refs/pull/*:refs/remotes/origin/pr/*
that you want this project to build pull requests only.
However, it seems that you have the Poll SCM trigger enabled along with the Github Pull Request Builder (GHPRB) trigger.
Remember, the GHPRB plugin is already a trigger. The only reason to enable additional triggers would be if you want to have this project also build normal branches. If this is the case, please see the bottom of this post for some more information about this use-case.
So step one is to make sure that the only trigger enabled is the GHPRB plugin.
The next step is to recognize that you are not using Github webhooks - likely due to firewall constraints. This means you are using a cronjob that will use the Github API to check for Pull Request updates and compare it to the last poll to detect changes.
This means that your credentials must be correct, first of all. You can check the credentials in the System Settings portion of Jenkins (you must be an Admin) under the GHPRB plugin section. Make sure the credentials have all the rights needed to view, comment, etc. your repository.
If all of that is correct, the logs will likely give you more information. If you are an admin, you can go to Manage Jenkins and find System Log. By viewing the log, you'll likely find errors that are related to your problem.
In your case, since I'm your sysadmin and am typing all of this for the benefit of a 3rd party who may come by, I noticed that we were seeing FileNotFound exceptions being thrown from the GitHub plugin when it attempted to access the API.
The cause?
The GHPRB plugin uses the Github plugin to communicate with the API and, thus, poll for Pull Requests. The Project url
field of the Github Plugin is used to generate the API URLs for the poll requests.
Remove the .git
portion of the URL! Even though it will work perfectly find when going to the URL in your browser, if you add the .git
suffix to the project name in the API it gets angry and will give you a 404
. By removing this suffix from the Project url
field, the GitHub plugin will parse the correct URL path for the API requests and life is good.
Building PRs and Normal Branches
In order to use a single Jenkins project for both Pull Requests and normal branches, you need to do a few extra things.
refspec
configuration to include not only the pull request refspec you have configured currently, but also the refspec(s) of the branches you wish to be built. For example, if you wanted all tags and branches to be available for building, you would use +refs/pull/*:refs/remotes/origin/pr/* +refs/heads/*:refs/remotes/origin/*
${sha1}
for building PRs and this environment variable is not created unless the build is triggered by the GHPRB plugin, you will want convert this project into a Parametarized Build and create a parameter called sha1
with a default value equal to the branch(es) you would normally have put under Branch Specifier if you weren't using the GHPRB plugin, and then ensure that the Branch Specifier field references the ${sha1}
variable. The GHPRB plugin will override this parameter if it is used to trigger the build, otherwise the default value will be used for other triggers. This also gives you a chance to manually run builds by specifying the parameter from the UI (or a script) at build-time.You may need a few other tweaks, but those are the main ones that come to mind immediately.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With