Pull request builds in Jenkins - Step-by-Step Execution

Process Flow - Pull request builds

Developer creates PR

↓

PR triggers Jenkins build

↓

Jenkins checks out PR code

↓

Run build and tests

↓

Build success?

No→Report failure to PR

Yes↓

Report success to PR

↓

PR can be merged

This flow shows how a pull request triggers a Jenkins build, runs tests, and reports results back to the PR.

Execution Sample

Jenkins

pipeline {
  agent any
  triggers {
    githubPullRequest()
  }
  stages {
    stage('Build and Test') {
      steps {
        sh 'make test'
      }
    }
  }
}

A Jenkins pipeline triggered by pull requests that runs tests on the PR code.

Process Table

Step	Action	Evaluation	Result
1	PR created in GitHub	PR event detected	Trigger Jenkins build
2	Jenkins checks out PR branch	Checkout success	Ready to build
3	Run 'make test'	Tests pass?	Yes
4	Report build status	Send success to GitHub	PR marked as successful
5	PR merge allowed	No conflicts, tests passed	PR can be merged
6	If tests fail	Report failure to GitHub	PR marked as failed, merge blocked

💡 Build ends after reporting status to GitHub and allowing or blocking merge.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
PR Status	Open	Checked out	Tests passed	Success reported	Merge allowed
Build Status	Not started	Running	Passed	Reported	Complete

Key Moments - 3 Insights

Why does Jenkins need to check out the PR branch instead of the main branch?

Jenkins checks out the PR branch to test the exact code changes in the pull request, as shown in step 2 of the execution table.

What happens if the tests fail during the build?

If tests fail (step 6), Jenkins reports failure back to GitHub and blocks the PR from merging, preventing broken code from entering main.

How does Jenkins know when to trigger a build for a pull request?

Jenkins listens for pull request events from GitHub (step 1), which triggers the build automatically.

Visual Quiz - 3 Questions

Look at the execution table, what is the build status after step 3?

A Failed

B Passed

C Not started

D Reported

💡 Hint

Check the 'Build Status' variable after step 3 in the variable_tracker.

At which step does Jenkins report the build result back to GitHub?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look for the action 'Report build status' in the execution_table.

If the tests fail, what is the effect on the pull request according to the execution flow?

A PR is marked as failed and merge is blocked

B Build is retried automatically

C PR is merged anyway

D Nothing happens

💡 Hint

Refer to step 6 in the execution_table and key_moments about test failure.

Concept Snapshot

Pull request builds trigger Jenkins to test PR code.
Jenkins checks out the PR branch, runs tests.
Build results are reported back to GitHub.
Success allows merge; failure blocks it.
Automates quality checks before merging code.

Full Transcript

When a developer creates a pull request, Jenkins detects this event and triggers a build. Jenkins then checks out the pull request branch to get the exact code changes. It runs the build and tests, such as 'make test'. If the tests pass, Jenkins reports success back to GitHub, marking the PR as successful and allowing it to be merged. If tests fail, Jenkins reports failure and blocks the merge to keep the main branch stable. This process automates quality checks on code changes before they are merged.

Practice

1. What is the main purpose of pull request builds in Jenkins?

easy

A. To automatically test code changes before merging

B. To deploy code directly to production

C. To delete old branches after merging

D. To manually review code without testing

Solution

1. Step 1: Understand pull request builds concept

   Pull request builds run tests automatically on code changes before merging to ensure quality.

2. Step 2: Compare options with purpose

   Only To automatically test code changes before merging describes automatic testing before merging, which is the main goal.

3. Final Answer:

   To automatically test code changes before merging -> Option A

4. Quick Check:

   Pull request builds = automatic pre-merge tests [OK]

Hint: Pull request builds test code before merging [OK]

Common Mistakes:

• Confusing deployment with testing
• Thinking pull request builds delete branches
• Assuming manual review replaces automated tests

2. Which Jenkins pipeline syntax correctly triggers a build on a GitHub pull request?

easy

A. triggers { githubPush() }

B. triggers { cron('H/5 * * * *') }

C. triggers { githubPullRequest() }

D. triggers { pollSCM('H/15 * * * *') }

Solution

1. Step 1: Identify trigger for pull request builds

   The correct trigger for GitHub pull request builds in Jenkins is githubPullRequest().

2. Step 2: Eliminate other triggers

   githubPush() triggers on push events, cron and pollSCM are time-based triggers, not pull request triggers.

3. Final Answer:

   triggers { githubPullRequest() } -> Option C

4. Quick Check:

   Pull request trigger = githubPullRequest() [OK]

Hint: Use githubPullRequest() for PR triggers [OK]

Common Mistakes:

• Using githubPush() instead of githubPullRequest()
• Confusing time-based triggers with PR triggers
• Omitting triggers block entirely

3. Given this Jenkinsfile snippet, what happens when a pull request is opened?

pipeline {
  agent any
  triggers {
    githubPullRequest()
  }
  stages {
    stage('Build') {
      steps {
        echo 'Building...'
      }
    }
  }
}

medium

A. The pipeline waits for manual approval before running

B. The pipeline runs automatically and prints 'Building...'

C. The pipeline runs only on push events, not pull requests

D. The pipeline fails due to syntax error

Solution

1. Step 1: Analyze trigger block

   The trigger githubPullRequest() starts the pipeline automatically on pull request events.

2. Step 2: Check pipeline steps

   The pipeline has a 'Build' stage that echoes 'Building...'. No manual approval or syntax errors are present.

3. Final Answer:

   The pipeline runs automatically and prints 'Building...' -> Option B

4. Quick Check:

   githubPullRequest() triggers automatic build [OK]

Hint: githubPullRequest() triggers auto build on PR [OK]

Common Mistakes:

• Assuming manual approval is needed
• Confusing push and pull request triggers
• Thinking syntax error exists in snippet

4. A Jenkins pipeline with githubPullRequest() trigger does not start when a pull request is created. What is the most likely cause?

medium

A. The GitHub webhook for pull requests is not configured

B. The Jenkinsfile has a syntax error in the stages block

C. The pipeline uses cron trigger instead

D. The pull request was merged before the build started

Solution

1. Step 1: Understand trigger requirements

   The githubPullRequest() trigger requires GitHub webhooks to notify Jenkins of PR events.

2. Step 2: Identify common failure reason

   If the webhook is missing or misconfigured, Jenkins won't start the build on PR creation.

3. Final Answer:

   The GitHub webhook for pull requests is not configured -> Option A

4. Quick Check:

   Missing webhook = no PR build trigger [OK]

Hint: Check GitHub webhook setup if PR builds don't start [OK]

Common Mistakes:

• Blaming syntax errors without checking webhooks
• Ignoring webhook configuration
• Assuming cron triggers handle PR events

5. You want Jenkins to build pull requests only from specific branches (e.g., 'feature/*') and skip others. Which configuration snippet achieves this?

hard

A. triggers { githubPullRequest { branchFilter { exclude 'feature/*' } } }

B. triggers { pollSCM { ignoreBranches 'feature/*' } }

C. triggers { githubPush { branch 'feature/*' } }

D. triggers { githubPullRequest { branchFilter { include 'feature/*' } } }

Solution

1. Step 1: Identify correct trigger and filter syntax

   The githubPullRequest trigger supports branchFilter with include to specify branches to build.

2. Step 2: Compare options for filtering

   triggers { githubPullRequest { branchFilter { include 'feature/*' } } } includes only 'feature/*' branches, which matches the requirement. triggers { githubPullRequest { branchFilter { exclude 'feature/*' } } } excludes them, which is opposite. Options C and D use wrong triggers or syntax.

3. Final Answer:

   triggers { githubPullRequest { branchFilter { include 'feature/*' } } } -> Option D

4. Quick Check:

   Use branchFilter include to limit PR builds [OK]

Hint: Use branchFilter include to build specific PR branches [OK]

Common Mistakes:

• Using exclude instead of include
• Using githubPush instead of githubPullRequest
• Trying to filter branches with pollSCM