Documented best way to autobuild from github PR?

Using Jenkins
,
1

A standard part of “CI”, I thought, would be auto-building from Pull Requests.
However, to my surprise, I have found no current documentation how to actually set that up from github PR.

I know that there is a 3-years-old “Github Pull Request” plugin, but that is now marked as unsecure.
I know that there is a new “Github Integrations” plugin (and is allegedly more secure), and it seems to be able to do the job… But there is no documentation I can find of how to “properly” set it up.

Does it exist?

In the forum suggestions, I did notice a 1 year old reference to

However, that is an INCREDIBLY long document, that rambles over multiple strategies, so is difficult to follow.

I infer that I should probably be using the Github Checks plugin.
However, the documentation for that seems out of date.

claims, “You can customize it by configuring the “Status Checks Properties” behavior for your GitHub SCM Source or Git SCM projects”

However, after installing the plugin and restarting Jenkins, there is no “status checks” area, either in the system global area, or in the org level folder that auto-recognizes all our repos currently.

Also, it is unclear to me how it would actually WORK.
The docs for “github check” does not say I need to set up webhooks on the github side.
Sooo… how does the call from github to jenkins, on a PR creation, happen?

2025: The Year in Review
2

The GitHub Branch Source plugin is the choice for this.
It automatically sets up builds for branches and Pull Requests. Requires that you have a Jenkinsfile in your branch, so only supports pipeline jobs.

3

I think that you want a multibranch Pipeline. There is the “branches and pull request” page in the Jenkins documentation

It also includes a video tutorial:

4

Thank you both for the suggestion.
I shall investigate this to see if it does what we need.

btw, we also want nightly polled auto-builds of the controller branch, in addition to builds for PRs.
But nothing else.

5

Doing a quick scan through both the jenkins doc mention, and that video… those seem to specifically be for local “git” only.

They dont seem to walk the viewer through how to integrate with gitHUB.
I think those docs are primarily is pull driven. vs how to deal with asynchronous push events, aka webhooks, from github.

Does that sound correct?

I really need help with the github specific integration aspects of things.

6

How about this video:

7

If you’d prefer an even higher level of integration, use can use a GitHub organization folder to scan across multiple repositories. This video:

8

That is for scheduled scanning though?
We already have that set up and working.

We need the async triggered-by-PR-creation builds to happen, which apparently is a completely different area of setup.

9

Thank you, this one seems a lot closer to our ideal.

It kind of suggests that the documentation for various plugins, (especially the “github pull request” plugin, which is deemed unsecure now!) should be updated to read,
“Obsolete: Go use Multibranch Pipeline instead” :slight_smile:

It’s nice in that it doesnt seem neccessary any more, to go into the github configuration for each repo to define custom webhooks any more.

However… this still seems to require some amount of manual, per-repo setup.
We would have to manually create a new “Multibranch Pipeline” item in the dashboard, every time someone creates a new repo. (and we have at present, 200 repos)

Is there a way to make this work for “org folder” setups?

I dont see the overlap in configuration.

In an ideal world, we would do a one-time setup, that would:

  1. autobuild all updates to “release” branch, for ALL repos
  2. autobuild checks for PR pushes, for ALL repos
  3. ignore everything else

and then never have to touch jenkins config ever again.

Is that possible?

10

I’m not seeing that type of manual setup per repo inside the ci.jenkins.io organization folders like the plugins folder . When a new plugin repository is created in GitHub, the ci.jenkins.io organization folder sees that there is a Jenkinsfile in the root of the primary branch of the repository. A job is automatically created for that new plugin without any interaction from a ci.jenkins.io administrator.

When a Jenkinsfile is detected in a repository in the organization, a Multibranch Pipeline folder is created for that repository.

11

well, that SOUNDS great then :slight_smile:
Only thing missing is a walkthrough for using an org folder instead of the multibranch pipeline.
They seem a little different.
Would also be nice to have the walkthrough explicitly call out “These are the plugins you need”.
I currently have a bunch of “github” named plugins, including the “github checks” plugin.
I’m concerned that some of these plugins may be overwriting the behaviour I need, so seems like it would be best for me to have a setup with just the plugins required.

12

I was feeling very hopeful about this and was looking forward to marking it as the answer.

But I didnt get to verify it. I did the recommended jenkins (upgrade to latest), by doing an upgrade to the latest.

Now it wont even start.
systemctl status and journalctl dont show any clear “This is broken pls fix” lines.
and there are no useful error log files that I can find to reference either.
example:

 ░░ The unit jenkins.service has entered the 'failed' state with result 'exit-code'.
Jan 15 20:29:08 jenkins-ci.c.software-builds.internal systemd[1]: Failed to start jenkins.service - Jenkins Continuous Integration Server.
░░ Subject: A start job for unit jenkins.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░ 
░░ A start job for unit jenkins.service has finished with a failure.
░░ 
░░ The job identifier is 7789 and the job result is failed.

Starting health checks at Wed Jan 15 20:25:37 UTC 2025
Health check results at Wed Jan 15 20:25:37 UTC 2025:
 * disk-space: Result{isHealthy=true, duration=0, timestamp=2025-01-15T20:25:37.802Z}
 * plugins: Result{isHealthy=true, message=No failed plugins, duration=0, timestamp=2025-01-15T20:25:37.802Z}
 * temporary-space: Result{isHealthy=true, duration=0, timestamp=2025-01-15T20:25:37.803Z}
 * thread-deadlock: Result{isHealthy=true, duration=0, timestamp=2025-01-15T20:25:37.803Z}

Jan 15 20:28:18 jenkins-ci.c.software-builds.internal systemd[1]: jenkins.service: Consumed 3.363s CPU time.
Jan 15 20:28:56 jenkins-ci.c.software-builds.internal systemd[1]: jenkins.service: Start request repeated too quickly.
Jan 15 20:28:56 jenkins-ci.c.software-builds.internal systemd[1]: jenkins.service: Failed with result 'exit-code'.
Jan 15 20:28:56 jenkins-ci.c.software-builds.internal systemd[1]: Failed to start jenkins.service - Jenkins Continuous Integration Server.
Jan 15 20:29:08 jenkins-ci.c.software-builds.internal systemd[1]: jenkins.service: Start request repeated too quickly.
Jan 15 20:29:08 jenkins-ci.c.software-builds.internal systemd[1]: jenkins.service: Failed with result 'exit-code'.
Jan 15 20:29:08 jenkins-ci.c.software-builds.internal systemd[1]: Failed to start jenkins.service - Jenkins Continuous Integration Server.