Custom notification logic in Jenkins - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Jenkins Pipeline: Notification on Build Status

Given the following Jenkins pipeline snippet, what will be the output notification message if the build fails?

Jenkins

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        script {
          currentBuild.result = 'FAILURE'
        }
      }
    }
  }
  post {
    failure {
      echo 'Build failed! Sending notification to team.'
    }
    success {
      echo 'Build succeeded! Sending success notification.'
    }
  }
}

A Build failed! Sending notification to team.

B No notification will be sent.

C Build succeeded! Sending success notification.

D Pipeline will error out due to invalid syntax.

💡 Hint

Check the post section and the currentBuild.result value.

The post block triggers the failure section when currentBuild.result is set to 'FAILURE'. So the failure message is printed.

❓ Configuration

intermediate

Configuring Email Notification in Jenkinsfile

Which of the following Jenkinsfile snippets correctly sends an email notification only when the build is unstable?

A

post {
  unstable {
    emailext subject: 'Build Unstable', body: 'Please check the build.', to: '[e-mail]'
  }
}

B

post {
  failure {
    emailext subject: 'Build Unstable', body: 'Please check the build.', to: '[e-mail]'
  }
}

C

post {
  always {
    emailext subject: 'Build Unstable', body: 'Please check the build.', to: '[e-mail]'
  }
}

D

post {
  success {
    emailext subject: 'Build Unstable', body: 'Please check the build.', to: '[e-mail]'
  }
}

💡 Hint

Look for the post condition that matches unstable builds.

The 'unstable' post condition triggers only when the build is unstable, so the email is sent only in that case.

❓ Troubleshoot

advanced

Why does the notification not send on build failure?

A Jenkins pipeline has this post block: post { failure { emailext subject: 'Build Failed', body: 'Check logs.', to: '[e-mail]' } } But no email is sent when the build fails. What is the most likely cause?

A The post block must be inside the stages block.

B The failure block only runs on unstable builds, not failures.

C The emailext plugin is not installed or configured properly.

D The 'to' email address is missing in the emailext step.

💡 Hint

Check plugin installation and configuration.

If the emailext plugin is missing or misconfigured, the email step will silently fail and no email will be sent.

🔀 Workflow

advanced

Custom Notification Logic with Scripted Pipeline

In a scripted Jenkins pipeline, which snippet correctly sends a Slack notification only if the build result is SUCCESS or UNSTABLE?

A

if (currentBuild.result != 'FAILURE') {
  slackSend channel: '#alerts', message: 'Build passed or unstable'
}

B

if (currentBuild.result == 'FAILURE' || currentBuild.result == 'UNSTABLE') {
  slackSend channel: '#alerts', message: 'Build passed or unstable'
}

C

if (currentBuild.result == 'SUCCESS' && currentBuild.result == 'UNSTABLE') {
  slackSend channel: '#alerts', message: 'Build passed or unstable'
}

D

if (currentBuild.result == 'SUCCESS' || currentBuild.result == 'UNSTABLE') {
  slackSend channel: '#alerts', message: 'Build passed or unstable'
}

💡 Hint

Use logical OR to check for multiple results.

The condition must check if result is either 'SUCCESS' or 'UNSTABLE' using || operator.

✅ Best Practice

expert

Best Practice for Avoiding Duplicate Notifications in Jenkins

Which approach best avoids sending duplicate notifications when using both 'post' blocks and manual notification steps inside stages?

A Send notifications both in stages and post blocks to ensure coverage.

B Centralize all notifications inside the 'post' block and avoid manual notifications in stages.

C Use manual notifications only and remove the post block entirely.

D Send notifications only in the first stage to avoid duplicates.

💡 Hint

Think about a single place to manage notifications.

Centralizing notifications in the post block ensures only one notification per build status, preventing duplicates.

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