📖 Scenario: You are managing a Jenkins pipeline that builds software projects. You want to send notifications only when the build fails or is unstable, to avoid spamming your team with success messages.
🎯 Goal: Create a Jenkins pipeline script that defines a custom notification logic. It should check the build status and send a notification only if the build result is FAILURE or UNSTABLE.
📋 What You'll Learn
Create a variable buildStatus with the current build result.
Define a list notifyStatuses containing FAILURE and UNSTABLE.
Write a conditional block that sends a notification only if buildStatus is in notifyStatuses.
Print a message indicating whether a notification was sent or skipped.
💡 Why This Matters
🌍 Real World
In real Jenkins pipelines, you often want to notify your team only when something goes wrong or needs attention, not on every successful build.
💼 Career
Understanding custom notification logic helps DevOps engineers reduce noise and improve communication in continuous integration workflows.
Progress0 / 4 steps
1
Set the build status variable
Create a variable called buildStatus and set it to the string FAILURE to simulate a failed build.
Jenkins
Hint
Use buildStatus = 'FAILURE' to assign the string.
2
Define notification statuses
Create a list called notifyStatuses containing the strings 'FAILURE' and 'UNSTABLE'.
Jenkins
Hint
Use square brackets to create the list: ['FAILURE', 'UNSTABLE'].
3
Add custom notification logic
Write an if statement that checks if buildStatus is in notifyStatuses. Inside the block, assign notificationSent the value True. Otherwise, assign notificationSent the value False.
Jenkins
Hint
Use if buildStatus in notifyStatuses: to check membership.
4
Print notification result
Write a print statement that outputs "Notification sent" if notificationSent is True, otherwise print "Notification skipped".
Jenkins
Hint
Use if notificationSent: to decide what to print.
Practice
(1/5)
1. What is the main purpose of using custom notification logic in Jenkins pipelines?
easy
A. To send notifications for every build regardless of status
B. To restart the Jenkins server automatically after each build
C. To disable all notifications permanently
D. To send notifications only when specific build conditions are met
Solution
Step 1: Understand notification goals
Custom notification logic aims to reduce noise by sending alerts only when necessary.
Step 2: Identify correct behavior
Sending notifications only on specific build results (like failure) keeps the team focused.
Final Answer:
To send notifications only when specific build conditions are met -> Option D
Quick Check:
Custom notifications = selective alerts [OK]
Hint: Think about reducing alert noise to stay focused [OK]
Common Mistakes:
Assuming notifications should always be sent
Confusing disabling notifications with custom logic
Believing Jenkins restarts after every build
2. Which Jenkins pipeline syntax correctly checks if the build failed before sending a notification?
easy
A. if (currentBuild.result = 'FAILURE') { notify() }
B. if (build.status == 'SUCCESS') { notify() }
C. if (currentBuild.currentResult == 'FAILURE') { notify() }
D. if (currentBuild.currentResult === FAILURE) { notify() }
Solution
Step 1: Identify correct property and comparison
Use currentBuild.currentResult to get build status and compare with string 'FAILURE'.
Step 2: Check syntax correctness
if (currentBuild.currentResult == 'FAILURE') { notify() } uses correct equality operator (==) and string comparison.
Final Answer:
if (currentBuild.currentResult == 'FAILURE') { notify() } -> Option C
Quick Check:
Correct property and comparison = if (currentBuild.currentResult == 'FAILURE') { notify() } [OK]
Hint: Use currentBuild.currentResult with 'FAILURE' string and == [OK]
Common Mistakes:
Using single equals (=) instead of double (==)
Comparing to SUCCESS instead of FAILURE
Missing quotes around 'FAILURE'
Using undefined variable FAILURE without quotes
3. Given this Jenkins pipeline snippet:
post {
failure {
script {
if (currentBuild.previousBuild?.result == 'SUCCESS') {
notify('Build failed after success')
}
}
}
}
What happens if the previous build was successful and the current build failed?
medium
A. Notification 'Build failed after success' is sent
B. No notification is sent
C. Notification is sent only if current build succeeded
D. Pipeline throws a syntax error
Solution
Step 1: Analyze condition in failure block
The post.failure block runs only if current build failed. Inside, it checks if previous build result was 'SUCCESS'.
Step 2: Evaluate condition outcome
If previous build was successful and current failed, condition is true, so notify is called with the message.
Final Answer:
Notification 'Build failed after success' is sent -> Option A
Quick Check:
Previous success + current failure triggers notification [OK]
Hint: Check previousBuild?.result and current failure block [OK]
Common Mistakes:
Thinking notification sends on success builds
Ignoring the safe navigation operator '?'
Assuming syntax error due to optional chaining
4. You wrote this Jenkins pipeline snippet to notify only on failure after success:
post {
failure {
script {
if (currentBuild.previousBuild.result == 'SUCCESS') {
notify('Failed after success')
}
}
}
}
But it sometimes throws a NullPointerException. What is the likely cause?
medium
A. notify function is undefined
B. previousBuild can be null, so accessing result causes error
C. failure block cannot contain if statements
D. currentBuild.previousBuild.result is always 'FAILURE'
Solution
Step 1: Identify potential null values
currentBuild.previousBuild can be null if no previous build exists.
Step 2: Understand error cause
Accessing result on null causes NullPointerException. Safe navigation operator ?. avoids this.
Final Answer:
previousBuild can be null, so accessing result causes error -> Option B
Quick Check:
Null previousBuild causes error without safe navigation [OK]
Hint: Use ?. to safely access previousBuild properties [OK]
Common Mistakes:
Ignoring possibility of null previousBuild
Assuming notify is always defined
Thinking failure block disallows if statements
5. You want to send a notification only when the build status changes from SUCCESS to FAILURE or from FAILURE to SUCCESS. Which Jenkins pipeline snippet correctly implements this logic?
hard
A. post {
failure {
script {
if (currentBuild.previousBuild?.result == 'SUCCESS') {
notify('Failed after success')
}
}
}
success {
script {
if (currentBuild.previousBuild?.result == 'FAILURE') {
notify('Succeeded after failure')
}
}
}
}
B. post {
success {
notify('Build succeeded')
}
failure {
notify('Build failed')
}
}
C. post {
always {
script {
if (currentBuild.previousBuild?.result != currentBuild.currentResult) {
notify('Build status changed')
}
}
}
}
D. post {
always {
notify('Build finished')
}
}
Solution
Step 1: Understand the requirement
Notify only when build status flips between SUCCESS and FAILURE, not on every build.
Step 2: Analyze each option
post {
failure {
script {
if (currentBuild.previousBuild?.result == 'SUCCESS') {
notify('Failed after success')
}
}
}
success {
script {
if (currentBuild.previousBuild?.result == 'FAILURE') {
notify('Succeeded after failure')
}
}
}
} checks previous build result and current build result in success and failure blocks separately, sending notifications only on status change.
Final Answer:
post {
failure {
script {
if (currentBuild.previousBuild?.result == 'SUCCESS') {
notify('Failed after success')
}
}
}
success {
script {
if (currentBuild.previousBuild?.result == 'FAILURE') {
notify('Succeeded after failure')
}
}
}
} -> Option A
Quick Check:
Status change detection needs previousBuild checks in success and failure blocks [OK]
Hint: Check previousBuild result differs from current in success and failure blocks [OK]
Common Mistakes:
Sending notifications on every build regardless of status change
Not checking previous build result
Using always block without condition
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.