|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I know that there's the pull requests plugin, we use it, but history has proven(to us) that having a single job handling all pull requests is not optimal. We have no unit test history for one, ie, we can't know if the PR has fixed or added additional failures with new commits unless we search which builds belong to which pull request.
Our current approach is to create a set of jobs per pull request, which will be managed by the pull requests plugin afterwards.
What we need is to know when a pull request is opened/closed, so we can trigger our pull request seed job. We are currently using url triggers which even trigger for GitHub ping events(also not optimal).
The same applies for branches creation/deletion, we want to be able to trigger a seed job to create/delete a set of jobs which will handle the branch.
As for the push notifications, we can't let the github-plugin auto manage hooks because we have a testing/staging/production jenkins setup and only one instance can be notified of pushes with the current plugin implementation.
So, ideally, we're after a push event notification which registers itself using webhooks, as opposed to the jenkins github hook app. It should do the awesome job that this plugin does for push notification, but using web hooks.
As for the other web-hook events, the plugin could just trigger the job and inject the payload into the build environment(we actually don't currently need the payload, but if it's going to be done, it should be done with a future mindset).
I tried hacking my way into the github-plugin to at least implement the events that I currently need as separate triggers, registering them using webhooks, but I'm not a java developer and I've lost a fair amount of time already and I didn't get it to work.