📖 Scenario: You work on a software project where developers submit code changes through pull requests on GitHub. To keep the project stable, you want Jenkins to automatically build and test each pull request before merging.
🎯 Goal: Set up a Jenkins pipeline that triggers a build whenever a pull request is created or updated on GitHub. This helps catch errors early and ensures code quality.
📋 What You'll Learn
Create a Jenkinsfile with a pipeline definition
Configure the pipeline to trigger on pull request events
Add a simple build stage that prints the pull request ID
Print a confirmation message when the build runs
💡 Why This Matters
🌍 Real World
Many teams use Jenkins to automatically build and test code changes submitted via pull requests to catch errors early and maintain code quality.
💼 Career
Understanding pull request builds is essential for DevOps engineers to automate CI/CD pipelines and improve collaboration between developers.
Progress0 / 4 steps
1
Create Jenkinsfile with pipeline block
Create a Jenkinsfile with a pipeline block that defines the pipeline structure.
Jenkins
Hint
The Jenkinsfile must start with the pipeline keyword followed by curly braces.
2
Add triggers for pull request events
Inside the pipeline block, add a triggers section with githubPullRequest() to trigger builds on pull request events.
Jenkins
Hint
Use the triggers block and add githubPullRequest() inside it.
3
Add a build stage to print pull request ID
Inside the pipeline block, add a stages section with one stage named Build. In the steps, add a script block that prints the pull request ID using env.CHANGE_ID.
Jenkins
Hint
Use echo inside a script block to print the pull request ID from env.CHANGE_ID.
4
Print confirmation message when build runs
Add a post section inside the pipeline block with a always block that prints Build completed for pull request ${env.CHANGE_ID}.
Jenkins
Hint
The post block runs after the pipeline. Use always to print the confirmation message.
Practice
(1/5)
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
Step 1: Understand pull request builds concept
Pull request builds run tests automatically on code changes before merging to ensure quality.
Step 2: Compare options with purpose
Only To automatically test code changes before merging describes automatic testing before merging, which is the main goal.
Final Answer:
To automatically test code changes before merging -> Option A
B. triggers { pollSCM { ignoreBranches 'feature/*' } }
C. triggers { githubPush { branch 'feature/*' } }
D. triggers { githubPullRequest { branchFilter { include 'feature/*' } } }
Solution
Step 1: Identify correct trigger and filter syntax
The githubPullRequest trigger supports branchFilter with include to specify branches to build.
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.
Final Answer:
triggers { githubPullRequest { branchFilter { include 'feature/*' } } } -> Option D
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.