I’m running a Jenkins instance with these GitHub-related plugins installed:
github-api
github
github-pull-request
My goal is to automatically start builds when pull requests get merged. The reason is that I have certain build processes that don’t run during PR validation, so I need fresh deployment artifacts created after merges happen.
The problem I’m facing is with GitHub Enterprise. Unlike the standard GitHub interface, I can’t find the webhook configuration options to specify which events should trigger the Jenkins plugin. It seems like only the default ‘push’ events are being handled. Is this setting located somewhere else in Enterprise, or is this a known limitation?
Update:
I managed to get the GitHub plugin working, but now it triggers builds on every single push when I enable it. I found some discussions suggesting that combining the Git SCM plugin with the GitHub plugin might work better. The idea is that the GitHub plugin detects changes, then the SCM plugin polls to check if the change affects the monitored branch.
However, when I configure both plugins together, no builds are triggered at all. Has anyone successfully set this up with Enterprise GitHub?
GitHub Enterprise webhooks are a pain because the payload structure is different from regular GitHub. Hit this exact issue moving our Jenkins from GitHub.com to Enterprise. Here’s what fixed it for me: set up the webhook at repo level with application/json content type, then use a groovy post-receive hook in Jenkins to parse the ref field. Enterprise changes some field names, especially for merge events. Rather than wrestling with multiple plugins that don’t play nice together, I wrote a simple groovy script in the job config. It checks for specific merge indicators in the webhook before triggering builds. Way cleaner and no plugin conflicts.
I switched to the Generic Webhook Trigger plugin instead of the standard GitHub plugin for Enterprise, and it solved this exact problem. GitHub Enterprise doesn’t handle event filtering like public GitHub does - that’s why you’re getting builds on every push. With the Generic Webhook Trigger plugin, you can manually parse the payload and set conditions based on specific JSON fields. I configured mine to only trigger when the payload shows “action”: “closed” and “merged”: true for pull request events. You’ll need to create a custom webhook URL in your Jenkins job config, then add that URL to your GitHub Enterprise repo webhooks with pull request events selected. Way better control over when builds actually run.
Been dealing with this exact headache at work. Jenkins plugins are honestly a pain to maintain, and GitHub Enterprise makes it worse with all the webhook configuration quirks.
I ditched Jenkins plugins entirely and moved to Latenode. Way cleaner.
Set up a simple webhook receiver in Latenode that listens for GitHub Enterprise events. You can filter for specific actions like pull request merges using the payload data. Then Latenode triggers your build pipeline through Jenkins API calls or whatever build system you’re using.
Best part is full control over the logic. Want to trigger only on merges to main branch? Easy conditional in Latenode. Need to skip builds for certain file changes? Parse the commit data and decide. No more fighting with conflicting plugins.
You can add extra steps like sending notifications, updating databases, or calling other APIs all in the same workflow. Much more flexible than making Jenkins plugins play nice together.
Takes 30 minutes to set up vs hours debugging plugin conflicts. Check it out: https://latenode.com
check your jenkins job config for the “build when a change is pushed to github” option. enterprise github sends different headers than regular github, so the plugin gets confused. i had to manually set the branch specifier to “origin/master” instead of just “master” to fix it.
I’ve encountered similar challenges with our GitHub Enterprise setup. The webhook configuration is actually found under ‘Integrations & services’ in the repository settings, not where you might expect in the main webhooks section. There, you can add a Jenkins service hook and specify the events you want to trigger.
I recommend avoiding the use of both plugins together, as they can conflict. We switched to using only the GitHub plugin with specific branch filtering in our job configuration. Make sure to set a branch pattern for your target branches, like master or main, and configure a build trigger that listens for merge events rather than regular pushes. Lastly, verify that the Jenkins webhook URL includes the /github-webhook/ path and that your GitHub Enterprise server can communicate with Jenkins without firewall issues.