Custom notification logic in Jenkins - Step-by-Step Execution

Process Flow - Custom notification logic

Build Starts

↓

Run Build Steps

↓

Check Build Result

↓

Send Success

↓

End Notification

The build runs, then checks the result. Based on success, failure, or unstable, it sends a custom notification accordingly.

Execution Sample

Jenkins

pipeline {
  agent any
  stages {
    stage('Build') {
      steps { echo 'Building...' }
    }
  }
  post {
    success { echo 'Notify: Build succeeded' }
    failure { echo 'Notify: Build failed' }
    unstable { echo 'Notify: Build unstable' }
  }
}

A Jenkins pipeline that runs a build and sends different notifications based on the build result.

Process Table

Step	Build Stage	Build Result	Notification Logic	Notification Sent
1	Start Build	N/A	No notification yet	None
2	Run Build Steps	N/A	No notification yet	None
3	Check Result	Success	Trigger success notification	Notify: Build succeeded
4	End	Success	No further notifications	None
5	Restart Build	Failure	Trigger failure notification	Notify: Build failed
6	End	Failure	No further notifications	None
7	Restart Build	Unstable	Trigger unstable notification	Notify: Build unstable
8	End	Unstable	No further notifications	None

💡 Build completes and notification sent based on final build result.

Status Tracker

Variable	Start	After Step 3	After Step 5	After Step 7	Final
buildResult	N/A	Success	Failure	Unstable	Unstable
notificationSent	None	Notify: Build succeeded	Notify: Build failed	Notify: Build unstable	Notify: Build unstable

Key Moments - 3 Insights

Why does the notification only send after the build finishes?

Because the notification logic runs in the 'post' section after all build steps complete, as shown in execution_table rows 3, 5, and 7.

What happens if the build is unstable? Does it send success or failure notification?

It sends the unstable notification only, as seen in execution_table row 7, not success or failure.

Can multiple notifications be sent for one build?

No, only one notification is sent based on the final build result, confirmed by the single notificationSent value per build in variable_tracker.

Visual Quiz - 3 Questions

Look at the execution table, what notification is sent at step 3?

A Notify: Build succeeded

B Notify: Build failed

C Notify: Build unstable

D None

💡 Hint

Check the 'Notification Sent' column at step 3 in the execution_table.

At which step does the build result become 'Failure'?

A Step 7

B Step 3

C Step 5

D Step 8

💡 Hint

Look at the 'Build Result' column in execution_table rows.

If the build result was always 'Success', how many notifications would be sent?

A Multiple notifications per build

B One notification per build

C No notifications

D Notifications only on failure

💡 Hint

Refer to variable_tracker showing notificationSent for 'Success' builds.

Concept Snapshot

Jenkins pipeline uses 'post' section for notifications.
Notifications depend on build result: success, failure, unstable.
Only one notification sent after build finishes.
Use 'success', 'failure', 'unstable' blocks in 'post' to customize.
This ensures clear, condition-based alerts.

Full Transcript

This visual execution shows how Jenkins custom notification logic works. The pipeline runs build steps, then checks the build result. Depending on whether the build succeeded, failed, or was unstable, it sends a matching notification. The notifications happen only after the build finishes, in the 'post' section. The execution table traces each step, showing when notifications trigger. The variable tracker records the build result and notification sent at each key step. Key moments clarify why notifications wait until the end and why only one notification is sent per build. The quiz tests understanding of notification timing and conditions. This helps beginners see exactly how Jenkins decides which notification to send.

Practice

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

1. Step 1: Understand notification goals

   Custom notification logic aims to reduce noise by sending alerts only when necessary.

2. Step 2: Identify correct behavior

   Sending notifications only on specific build results (like failure) keeps the team focused.

3. Final Answer:

   To send notifications only when specific build conditions are met -> Option D

4. 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

1. Step 1: Identify correct property and comparison

   Use currentBuild.currentResult to get build status and compare with string 'FAILURE'.

2. Step 2: Check syntax correctness

   if (currentBuild.currentResult == 'FAILURE') { notify() } uses correct equality operator (==) and string comparison.

3. Final Answer:

   if (currentBuild.currentResult == 'FAILURE') { notify() } -> Option C

4. 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

1. 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'.

2. Step 2: Evaluate condition outcome

   If previous build was successful and current failed, condition is true, so notify is called with the message.

3. Final Answer:

   Notification 'Build failed after success' is sent -> Option A

4. 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

1. Step 1: Identify potential null values

   currentBuild.previousBuild can be null if no previous build exists.

2. Step 2: Understand error cause

   Accessing result on null causes NullPointerException. Safe navigation operator ?. avoids this.

3. Final Answer:

   previousBuild can be null, so accessing result causes error -> Option B

4. 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

1. Step 1: Understand the requirement

   Notify only when build status flips between SUCCESS and FAILURE, not on every build.

2. 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.

3. 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

4. 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