A pull request builder is an automatic checker that builds and tests proposed code changes before anyone merges them.

First, the basics

Jenkins is a free automation server. Teams use it to build software, test it, and deliver it. A build is one run of that automation: fetch the code, compile it, run the tests, and report the result.

Most teams keep their code in Git, a system that tracks every change. Work usually happens on a branch, a separate line of changes that does not disturb the main code. When the work is ready, the developer opens a pull request, often shortened to PR. It is a formal request that says, “please review my branch and merge it into the main branch.” On some platforms, such as GitLab, the same thing is called a merge request.

So what is the builder?

The pull request builder is the part of your Jenkins setup that notices pull requests and builds them automatically. Whenever a PR is opened, updated with new commits, or reopened, Jenkins starts a build. When it finishes, Jenkins reports the outcome back to the pull request as a green tick or a red cross.

What does it give you?

• Early warning: broken code is caught before it is merged, not after.
• Fast feedback: the developer learns about a problem minutes after pushing, while the change is still fresh in mind.
• Reviewer confidence: a reviewer sees a green check and can focus on design, not on wondering whether it even compiles.
• A protected main branch: the platform can refuse to merge until the check passes.

Teams learned, often painfully, that testing only after merging is testing too late.

The old way

In the early days of continuous integration, developers pushed changes straight to a shared branch. Jenkins built that branch after every push. If the build failed, the whole team was blocked, everyone’s next change was built on top of the broken one, and somebody had to stop work to find out who had broken what.

The pull request workflow

Hosting platforms such as GitHub popularised pull requests around 2008 onwards. Suddenly there was a natural checkpoint: a proposal that has not been merged yet. It was the perfect place to run tests. The first Jenkins answer was a community plugin named the GitHub Pull Request Builder, often called ghprb. It watched a repository for pull requests, built each one, and posted the result as a comment and a status.

The modern way

As Jenkins moved toward Pipeline as code, a newer approach appeared: the multibranch pipeline together with a branch source plugin, such as the GitHub Branch Source plugin. Instead of one special job that reacts to pull requests, Jenkins scans the repository, finds branches and pull requests itself, and creates a pipeline for each one, using the Jenkinsfile stored in the code. The older ghprb plugin is no longer the recommended path for new setups, and many teams have migrated away from it.

Real-world motivation

Large open-source projects receive changes from hundreds of strangers. Without automatic checks on every proposal, maintainers would spend all day compiling other people’s code by hand. Pull request builders turn that chore into a background service, and this is why they are standard practice in both open-source and company projects today.

A handful of ideas explain almost everything about pull request builds.

Vocabulary table

Four parties cooperate: the developer, the code host, the Jenkins controller, and the agents that do the work.

The players

The developer pushes commits and opens the pull request. The code host, such as GitHub, Bitbucket, or GitLab, stores the repository and shows the pull request page. The controller is the Jenkins brain: it receives notifications, decides what to build, and reports results. An agent is a worker machine or container that actually compiles and tests the code.

flowchart LR
    DEV["Developer"] -->|"Push and open PR"| HOST["Code Host"]
    HOST -->|"Webhook"| CTRL["Jenkins Controller"]
    CTRL -->|"Scan repository"| HOST
    CTRL --> Q["Build Queue"]
    Q --> AG["Agent"]
    AG -->|"Clone PR code"| HOST
    AG --> TESTS["Build and Tests"]
    TESTS --> CTRL
    CTRL -->|"Status check"| HOST
    HOST --> PRPAGE["PR Page shows green or red"]
    PRPAGE --> DEV

Reading the diagram

The developer pushes code and opens a pull request. The code host immediately sends a webhook to Jenkins. Jenkins may scan the repository to learn the details, then places a build in the queue. When an agent is free, it downloads the pull request code, builds it, and runs the tests. The controller collects the result and sends a status to the code host. The pull request page then shows a green tick or a red cross, and the developer sees it without leaving the page.

Where the settings live

With the modern approach, the pipeline steps live in a file called a Jenkinsfile inside the repository, so each pull request can carry its own changes to the pipeline. The connection details, such as which repository to watch and which credentials to use, live in the Jenkins job configuration.

There is no magic here. Jenkins follows a short, predictable routine for every pull request.

Step one: hearing about the pull request

Jenkins learns about a pull request in one of two ways. Either the code host sends a webhook the moment something happens, or Jenkins asks the code host on a schedule, a practice called polling. Webhooks are faster and lighter. Polling is a safety net for the times when a webhook gets lost.

Step two: discovering the details

Jenkins asks the code host for facts about the pull request: its number, its title, its author, the branch it comes from, the branch it targets, and the latest commit. It records these details so the build can use them later.

Step three: choosing what code to test

A pull request has two useful versions. The head is the developer’s branch exactly as pushed. The merge result is what the target branch would look like after merging the pull request. Code hosts such as GitHub keep a special reference for the merge result and update it automatically. Jenkins can build the head, the merge result, or both. Building the merge result is usually the most honest test, because it shows what will really exist after the merge.

Step four: the checkout

The agent downloads the chosen version of the code. To do this, it asks Git for special references that the code host provides for pull requests. Ordinary branch downloads do not include them, so the job must be told to fetch them.

Step five: running the pipeline

The agent runs the steps: compile, test, analyse, package. Jenkins gives the pipeline extra information about the pull request through environment variables, which are named values available to every step, such as the pull request number and the target branch.

Step six: reporting

Jenkins sends status messages to the code host: “pending” when the build starts, then “success” or “failure” when it ends. The code host shows them next to the pull request and can use them to allow or block the merge.

Follow one pull request from the first push to the final merge and see every message that passes between the systems.

sequenceDiagram
    participant D as Developer
    participant H as Code Host
    participant J as Jenkins Controller
    participant A as Agent
    participant R as Reviewer
    D->>H: Push branch and open pull request
    H->>J: Webhook with PR details
    J->>H: Set status pending
    J->>A: Queue and start build
    A->>H: Clone PR merge result
    A->>A: Compile and run tests
    A-->>J: Result and logs
    J->>H: Set status success or failure
    H-->>D: Show check on PR page
    R->>H: Review and approve
    H->>H: Merge allowed only if checks pass
    D->>H: Push a fix
    H->>J: New webhook and new build

The lifecycle in plain steps

What happens when the target branch moves

While a pull request waits for review, other changes merge into the target branch. The pull request is now behind. Depending on your settings, Jenkins may build the pull request again when the target changes, or may leave the old result in place until the next push. Teams often require pull requests to be up to date before merging, so that the final check matches the final state.

The plugin known as ghprb was the first popular answer. You will still meet it in older Jenkins installations.

How it works

You create an ordinary Jenkins job, often a freestyle job, and switch on the pull request trigger. The plugin then checks the GitHub repository on a schedule or through a webhook. When it sees a new or updated pull request, it starts your job, passes pull request details as parameters, and afterwards posts the result as a comment and a commit status.

Access lists

Because building a stranger’s code is risky, the plugin uses lists of people:

• Admin list: people who may approve builds and manage the trigger through comments.
• Whitelist: people whose pull requests are built automatically.
• Organisation whitelist: everyone in a named GitHub organisation is trusted.

Pull requests from anyone else wait until a trusted person approves them with a comment such as “ok to test.” Other typical comment phrases include one to build once (“test this please”) and one to rebuild (“retest this please”).

Strengths and weaknesses

This is the modern, recommended way. Jenkins discovers branches and pull requests by itself and builds each one with the Jenkinsfile stored in the code.

The pieces

A multibranch pipeline is a job that manages a whole family of pipelines. Given a repository, it creates one child pipeline for every branch and, if enabled, for every pull request. A branch source plugin teaches Jenkins how to talk to a specific code host. Examples include GitHub Branch Source, Bitbucket Branch Source, and GitLab Branch Source. An organisation folder goes one level higher: it scans an entire GitHub organisation or account and creates a multibranch job for each repository that contains a Jenkinsfile.

How discovery works

Jenkins scans the repository and lists its branches and pull requests. For each one, it checks whether a Jenkinsfile exists. If so, it creates a child pipeline, named after the branch or, for pull requests, in the form “PR-” followed by the number. Scans happen when a webhook arrives, and can also happen on a timer.

Discovery settings

Why teams prefer it

Both approaches work. Which one fits your team depends on where your code lives and how your builds are defined.

flowchart TD
    S["Need automatic builds for pull requests"] --> P{"Do you use Pipeline as code with a Jenkinsfile?"}
    P -->|"Yes"| M["Use multibranch pipeline with a Branch Source plugin"]
    P -->|"No, old freestyle jobs"| Q{"Can you move to a Jenkinsfile?"}
    Q -->|"Yes, plan migration"| M
    Q -->|"No, not for now"| G{"Code host is GitHub?"}
    G -->|"Yes"| C["Keep the classic plugin and plan to migrate"]
    G -->|"No"| O["Use the host specific plugin or a generic webhook trigger"]

Side by side

A simple rule of thumb

If you are starting fresh, choose multibranch pipelines. If you have an old setup that works, keep it running while you plan a step-by-step migration. Do not begin a new project on a legacy plugin.

How quickly Jenkins learns about a pull request decides how quickly developers get feedback.

Webhooks: the doorbell

A webhook is a message that the code host sends to a web address you provide. You register a Jenkins address in the repository or organisation settings, and choose which events to send: pull request opened, updated, or closed, and pushes to branches. When one of these events occurs, the code host immediately notifies Jenkins, and the build starts within seconds.

Polling and periodic scans: the safety net

Polling means that Jenkins asks the code host, “anything new?” at fixed intervals. It is slower, and on large installations it can create heavy traffic, so most teams use it only as a backup. Webhooks can fail. A firewall may block them, Jenkins may be restarting at that moment, or the code host may have an outage. A periodic rescan, for example once every few hours, catches whatever the webhooks missed.

Reaching Jenkins safely

If Jenkins lives inside a private network, the code host cannot reach it directly. Teams solve this with a reverse proxy in front of Jenkins that exposes only the webhook path, or with a relay service that forwards messages into the private network. Whatever you choose, restrict the exposed address so that only the webhook endpoint is public, and use the code host’s secret feature to verify that messages really come from it.

This single setting changes what your green tick actually means.

The three choices

Which should you choose?

For most teams, the merge result is the best default, because it tests what matters: the code that will really exist. The head-only choice is faster to reason about and never changes because of other people’s work, which can be helpful for very large or slow builds. Building both is useful while you learn, since a difference between the two tells you the target branch has moved in a way that affects the change.

Names of the checks

When Jenkins reports both builds to GitHub, it uses two distinct check names, one for the head build and one for the merge build. You can then choose which one your branch protection rule requires. Requiring the merge check gives the strongest protection.

The moving target problem

The merge result changes whenever the target branch changes, even if the developer does nothing. A pull request that was green yesterday can turn out to be stale today. Some teams close this gap by requiring branches to be up to date before merging, and some use a merge queue, a feature of certain code hosts that tests the final combination one change at a time before it lands.

Jenkins hands the pipeline a set of facts about the pull request, so your steps can behave differently for pull requests than for ordinary branches.

Useful environment variables

These variables exist only for builds that come from a pull request, which gives you an easy way to detect one: if CHANGE_ID has a value, this build belongs to a pull request.

Stage conditions

Declarative Pipeline lets a stage carry a condition. One common condition is changeRequest, which is true only in pull request builds. Another lets you test the target branch or the branch name. With these, you can shape the pipeline:

• Run quick tests and static analysis on every pull request.
• Run slow, expensive tests only on the main branch or before release.
• Deploy only from the main branch, never from a pull request.
• Publish artifacts, meaning built packages, only after merge.

Changed-file conditions

A pipeline can also ask which files a change touched, and skip stages that do not apply. A pull request that edits only documentation may not need the full integration test suite. This is helpful but must be used carefully, so that a path rule never silently skips an important check.

A build that nobody sees is a build that nobody trusts. Reporting closes the loop.

Commit statuses

The simplest report is a commit status. Jenkins sends the code host a small message: this commit, this check name, this state (pending, success, failure, or error), and a link to the build. The pull request page then shows a line such as “continuous-integration/jenkins” with a coloured icon. Clicking it opens the Jenkins build.

Rich checks

Some code hosts also support richer checks, which can show a title, a summary, annotations on specific lines of code, and details inside the pull request page itself. Jenkins can publish these through a checks plugin. Annotations are especially helpful: a failing test or a style warning can appear directly on the line that caused it, so the developer never needs to open Jenkins.

Branch protection: making checks count

A check that can be ignored will be ignored. Branch protection rules on the code host make the checks mandatory. You can require that specific checks pass, that reviewers approve, that conversations are resolved, and that the branch is up to date. Only then does the merge button turn on. Without protection, the pull request builder is only advice. With protection, it is a gate.

Naming and stability

Required checks are matched by name. If you rename a check in Jenkins, the protection rule may wait forever for a check that no longer exists, and every pull request becomes unmergeable. Treat check names like a public contract. Rename only with a plan, and update the protection rules at the same time.

A pull request builder runs somebody else’s code on your machines. That is the most dangerous sentence in this guide.

The core risk

Building a pull request means compiling and running whatever the author wrote, including the test code and, in the modern approach, the Jenkinsfile itself. A malicious or careless author could add a step that steals passwords, mines cryptocurrency, or attacks your internal network. Any credential visible to the build is visible to the author’s code.

Trust policies

Branch source plugins let you define how far to trust pull request authors. Typical levels are:

Untrusted pull requests use the trusted Jenkinsfile

For an untrusted pull request, Jenkins builds the code but reads the Jenkinsfile from the target branch, not from the pull request. This stops a stranger from rewriting the pipeline to steal secrets. It does not stop tests or build scripts inside the changed code from doing harm, which is why untrusted builds should run in a strongly isolated place.

Protecting secrets

• Give pull request builds access to as few credentials as possible, ideally none.
• Keep deployment and publishing credentials in separate jobs or folders that pull request builds cannot use.
• Use short-lived, narrowly scoped credentials for anything a build must reach.
• Never print secrets to the log, and remember that a build script can print them anyway.

Isolation of the machines

Run pull request builds on disposable agents, such as fresh containers deleted after each run. Give them no route to internal databases or management networks. If a build gets compromised, the damage then ends when the container disappears.

A busy team can open dozens of pull requests an hour. The builder must keep up, or feedback turns slow and developers lose trust.

Where time and money go

Every push to a pull request may start a build. If a developer pushes ten times an hour and each build takes twenty minutes, one person alone can occupy several agents. Multiply by a team of fifty and the queue explodes.

Practical remedies

Concurrency and the queue

Set sensible limits so one repository cannot take over every agent. Use labels to send heavy builds to strong machines and light builds to small ones. Watch the average time a build waits in the queue. If waiting grows longer than building, you need more capacity.

Scanning cost

Scanning a large organisation with thousands of repositories and branches can put load on both Jenkins and the code host, and can run into the host’s rate limits. Prefer webhooks over frequent scans, restrict discovery to repositories that really contain a Jenkinsfile, and stretch the periodic scan interval.

When the pull request builder fails, developers cannot merge. It deserves the care of a production service.

What can go wrong

• Lost webhooks: a pull request never gets built.
• Jenkins down: pending checks never finish, and merging is blocked.
• Code host outage: Jenkins cannot download code or report results.
• Agent shortage: builds wait in the queue for hours.
• Flaky tests: tests that fail randomly make good code look bad.

Defences

A fallback plan

Decide in advance what happens when Jenkins is down for a long time. Some teams allow trusted maintainers to merge urgent fixes without the check, but only with a written record. Having the rule before the outage prevents panic decisions during it.

You cannot improve what you cannot see. A pull request builder produces plenty of numbers worth watching.

The numbers that matter

Time to feedback is the most important measure of all. It is the total delay between a developer pushing code and learning the verdict. When it grows past about ten minutes, developers switch to other tasks, lose context, and stop caring about the result. Many teams set a target and treat a slow build like a bug.

More measures worth tracking

• Flaky test rate: how often the same code passes and fails.
• Rebuild count: how many times developers press re-run on the same commit. High numbers reveal instability.
• Stage duration: which stage takes the longest, so you know where to invest.
• Agent utilisation: whether machines are idle or overloaded.
• Webhook delivery: whether messages from the code host are being received.
• Scan duration and errors: how long repository scans take, and how often they hit rate limits.

Good logs

Write log lines for humans in a hurry. Begin each build by printing the pull request number, the author, the target branch, and the version of the code being tested. Mark the beginning and end of each stage. When a test fails, print a short reason near the end of the log, not buried in ten thousand lines. Use Jenkins features that gather test results into a summary page, so people find failures in one click.

Alerts

Alert the owning team when the queue grows abnormally, when scans fail repeatedly, when webhook traffic drops to zero during working hours, or when the failure rate of the main branch suddenly rises. Do not alert individual developers about their own red builds by message storm; the pull request page is already telling them.

The best pull request pipeline is fast, honest, and easy to understand. It answers one question: is this change safe to merge?

Think in tiers

Fail fast

Order the stages so that the cheapest checks come first and the slowest come last. A missing semicolon should fail in thirty seconds, not after fifteen minutes of compiling. Where stages do not depend on each other, run them in parallel.

Honest tests

A pull request pipeline is only useful when its verdict can be trusted. Tests must be repeatable: the same code should give the same result every time. They must not depend on the order of other tests, on the current time, or on shared external services that go down. Use fresh test data, disposable databases in containers, and fake versions of outside services.

Keep the pipeline in the repository

Store the Jenkinsfile beside the code. When a developer adds a new test type, the same pull request updates the pipeline. Reviewers see both changes together, and the pipeline always matches the code it builds.

Reuse through shared libraries

If many repositories need the same steps, keep them in a Jenkins shared library, so each repository’s Jenkinsfile stays short. A central change then improves every pull request builder at once.

A pull request builder is infrastructure. Treat its setup as code, so you can rebuild it, review it, and grow it.

Describe Jenkins in files

The Jenkins Configuration as Code plugin lets you describe the Jenkins system in a text file: security settings, credentials references, agent definitions, and even job creation. The Job DSL plugin lets you define jobs, such as the organisation folder that watches your repositories, in code. Keeping these files in source control means a lost controller can be rebuilt from the repository, and every change goes through review.

flowchart LR
    CODE["Configuration as Code Files"] --> JC["Jenkins Controller"]
    ORG["Organisation Folder Definition"] --> JC
    HOST["Code Host with Webhooks"] --> JC
    JC --> K["Elastic Container Agents"]
    K --> ISO["Isolated Network Zone"]
    K --> CACHE["Shared Dependency Cache"]
    JC --> STAT["Status and Checks back to Code Host"]
    JC --> MON["Metrics and Alerts"]

Elastic agents in the cloud

Modern setups often start a fresh container for every build, using a container platform such as Kubernetes or a cloud provider’s virtual machines. The container has the tools the build needs, does its job, and disappears. This gives three benefits: builds do not disturb each other, there are no leftover files or secrets, and capacity grows during busy hours and shrinks at night, which saves money.

Preview environments

Some teams go a step further and create a temporary running copy of the application for every pull request, called a preview environment. Reviewers can click a link in the pull request and try the change live. The environment is deleted when the pull request closes. This is powerful for web applications, but it needs careful cost controls and automatic cleanup.

Secrets in the cloud

Use a secret store or Jenkins credentials, and give pull request builds only the narrow, short-lived access they need. Prefer identities that the platform issues for a single build, rather than long-lived passwords copied into settings.

Pull request builds are one of the highest-value practices in software delivery, and they still have costs.

Speed versus thoroughness

The false comfort problem

A green tick means only that the tests you wrote did not fail. If the tests are thin, the tick tells you very little. A pull request builder is a machine for enforcing your standards, and it can enforce only the standards you have actually written down as checks. Invest as much in the quality of the tests as in the quality of the plumbing.

There is no universal answer. A small team with a fast test suite can afford full checks on every push. A large organisation with slow tests must choose carefully which checks belong before merge and which belong after.

A pattern is a solution many teams discovered independently. An anti-pattern is a trap many teams fell into.

Patterns worth copying

Anti-patterns to avoid

These are the lessons that teams usually learn the hard way. You can learn them the easy way.

Best practices

• Use multibranch pipelines with a branch source plugin for new setups.
• Use webhooks, and keep a periodic rescan as a safety net.
• Test the merge result, not only the branch head.
• Keep the required checks fast, ideally under ten minutes.
• Cancel superseded builds to save capacity.
• Report a pending status immediately and a final status always, even on failure or timeout.
• Turn on branch protection so checks are mandatory.
• Trust as few outside authors as possible, and isolate their builds.
• Keep secrets away from pull request builds.
• Set timeouts on builds and stages.
• Track flaky tests and time to feedback.
• Keep Jenkins configuration in code, so it can be rebuilt.

Common mistakes and their fixes

Let us walk through a complete setup for a fictional team, step by step, without writing any code.

The situation

BrightCart is a company with twelve repositories on GitHub. Each has a web service written in a common language. Developers open around thirty pull requests a day. So far, testing happens by hand before merging, and twice last month a broken change reached the main branch. The team asks you to set up automatic pull request builds.

Step by step

The result after one month

Many teams still run pull request builds through the older plugin. Here is how to move to multibranch pipelines without disruption.

What is different

The classic plugin keeps its configuration in a Jenkins job and stores build steps there too. Multibranch pipelines keep the steps in a Jenkinsfile in the repository and create a separate pipeline for every pull request. The move therefore has two parts: turning job steps into a Jenkinsfile, and replacing the trigger with automatic discovery.

A safe migration path

The reward

After migration, pipeline changes are reviewed with the code, each pull request has its own build history, new repositories join automatically, and the setup uses actively maintained plugins.

A pull request builder is a tool, but it works best when the team agrees on how to use it.

Agree on what green means

Write a short sentence, such as: “A green check means the merged code compiles, passes unit and integration tests, and has no new security warnings.” Put it in the contributing guide so that everyone shares one understanding.

Agree on time

Set a target for time to feedback, for example under ten minutes for required checks. When builds exceed it, treat the slowdown as a problem worth fixing, just like a bug.

Agree on red builds

• The author owns a red pull request and fixes it or asks for help quickly.
• Reviewers do not review pull requests with failing checks, except to help diagnose.
• Nobody merges around a red check without a written reason and a second person’s approval.
• A broken main branch is fixed or reverted first, before any other work.

Agree on flaky tests

Decide how a flaky test is reported, who owns fixing it, and how long it may stay quarantined. A shared list of flaky tests with owners prevents them from being forgotten.

Agree on outside contributors

Decide who reviews pull requests from strangers, how they are approved to build, and what extra checks apply. Write this down publicly if your project is open source, so contributors know what to expect.

These scenarios show how organisations use pull request builders. They are illustrative, so you can map them to your own situation.

What these examples share

In each case, the pull request builder is part of a wider agreement: automatic checks, mandatory protection, careful trust, and quick feedback. The tool is important, but the habits around it are what produce a healthy main branch.

Every modern CI system offers some way to test proposals before merging. Comparing them shows what is essential.

What Jenkins does differently

Jenkins does not come bundled with the code host. You connect the two through plugins, webhooks, and credentials. That gives freedom: you can choose any code host, run builds on your own machines, and shape the process however you like. The cost is responsibility for plugins, upgrades, scaling, and security. Hosted tools carry more of that burden for you.

What is universal

The lessons apply everywhere: test the merge result, keep required checks fast, mark checks as mandatory, isolate untrusted code, protect secrets, watch flaky tests, and measure time to feedback. If you learn these habits with Jenkins, you can carry them to any tool.

Once the basics feel comfortable, these features help larger teams.

Comment commands

Some teams like to control builds from the pull request page by typing short commands in comments, such as a request to rebuild or to run an extra test suite. The classic plugin offered this out of the box. In the modern approach, you can get similar behaviour with extra plugins or with a small service that listens to comment events and asks Jenkins to start a build. Restrict such commands to trusted people, since a comment that starts a build spends real capacity and may run untrusted code.

Monorepos

A monorepo holds many projects in one repository. Running everything for every pull request would take too long. Two common answers exist. First, use changed-file rules to run only the stages that matter for the touched folders. Second, use a build tool that understands dependencies between projects and rebuilds only the affected ones. Both need care, because a wrong rule can skip a test that should have run.

Merge queues

When many pull requests are ready at the same time, each one may be green on its own but conflict with the others once merged together. A merge queue, offered by some code hosts, lines up approved pull requests and tests each on top of the ones ahead of it before merging. Jenkins can take part by building the queue’s combined state and reporting a check. This keeps the main branch always green, at the cost of extra builds.

Required approvals before building

For public projects, a first-time contributor’s pull request can wait for a maintainer’s approval before any build starts. This costs a little time and protects capacity and secrets from abuse.

Pull request labels and skipping builds

Some teams allow labels to change behaviour: a label that requests an extra slow test suite, or a label that marks a documentation-only change. Make such rules visible and limited. If labels can skip important checks, they must be controlled by people with the right authority.

Cleaning up

Closed pull requests leave jobs and workspaces behind. Set an orphaned item strategy so old ones are removed after a number of days or after a fixed count. Also clear workspaces on agents. Without cleanup, disks fill up and Jenkins slows down.

When something feels wrong, walk through these questions in order.

Every important word from this guide in one place, explained in plain language.

Short answers to the questions people ask most.

A pull request builder turns code review from a hopeful process into a checked one.

You started with a bakery that put untested cakes on the shelf and finished with a full tasting process. Along the way you learned how Jenkins discovers pull requests, decides which code to test, reports the result, protects itself from untrusted code, scales with demand, and stays reliable. The main rules are simple: use multibranch pipelines, test the merge result, keep the required checks fast, make them mandatory, isolate untrusted builds, and watch time to feedback.