Post-build actions in Jenkins - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to add a post-build action that archives artifacts.

Jenkins

post {
  always {
    archiveArtifacts artifacts: '[1]'
  }
}

Drag options to blanks, or click blank then click option'

A**/*.jar

Bbuild.log

Csrc/**

DREADME.md

Attempts:

3 left

💡 Hint

Common Mistakes

Using a single file name instead of a pattern.

Forgetting to include the wildcard for all folders.

The pattern **/*.jar archives all JAR files from all folders after the build.

2fill in blank

medium

Complete the code to send an email notification after the build.

Jenkins

post {
  failure {
    mail to: '[1]', subject: 'Build Failed', body: 'Please check the build logs.'
  }
}

Drag options to blanks, or click blank then click option'

[e-mail]

Bbuild@localhost

[e-mail]

[e-mail]

Attempts:

3 left

💡 Hint

Common Mistakes

Using a local or personal email address instead of the team email.

Leaving the email field empty.

The email should be sent to the development team, so [e-mail] is the correct recipient.

3fill in blank

hard

Fix the error in the post-build action that triggers a downstream job.

Jenkins

post {
  success {
    build job: '[1]'
  }
}

Drag options to blanks, or click blank then click option'

ADeployApp

Bdeployapp

CDeploy_App

Ddeploy-app

Attempts:

3 left

💡 Hint

Common Mistakes

Using lowercase or incorrect separators in job names.

Misspelling the job name.

The job name is case-sensitive and usually uses PascalCase like DeployApp.

4fill in blank

hard

Fill both blanks to add a post-build action that triggers only when the build is unstable and waits for completion.

Jenkins

post {
  unstable {
    build job: '[1]', wait: [2]
  }
}

Drag options to blanks, or click blank then click option'

ARunTests

Btrue

Cfalse

DDeploy

Attempts:

3 left

💡 Hint

Common Mistakes

Setting wait to false when you want to wait.

Using a job name unrelated to testing or unstable builds.

The job RunTests is triggered, and wait: true makes Jenkins wait for the job to finish.

5fill in blank

hard

Fill all three blanks to archive logs only if the build is successful and notify the team.

Jenkins

post {
  success {
    archiveArtifacts artifacts: '[1]'
    mail to: '[2]', subject: '[3]'
  }
}

Drag options to blanks, or click blank then click option'

A**/logs/*.log

[e-mail]

CBuild Success Notification

[e-mail]

Attempts:

3 left

💡 Hint

Common Mistakes

Using the QA team email instead of the dev team.

Incorrect artifact pattern that misses log files.

Logs matching **/logs/*.log are archived. The dev team is notified with the subject Build Success Notification.

Practice

1. What is the main purpose of Post-build actions in Jenkins?

easy

A. To start the build process

B. To write the build script

C. To perform tasks automatically after the build finishes

D. To configure the Jenkins server settings

Solution

1. Step 1: Understand Jenkins build phases

   Jenkins runs build steps first, then post-build actions after the build ends.

2. Step 2: Identify the role of post-build actions

   Post-build actions automate tasks like notifications, archiving, or cleanup after the build completes.

3. Final Answer:

   To perform tasks automatically after the build finishes -> Option C

4. Quick Check:

   Post-build actions = tasks after build [OK]

Hint: Post-build actions run after build ends to automate tasks [OK]

Common Mistakes:

• Confusing post-build actions with build steps
• Thinking post-build actions start the build
• Assuming post-build actions configure Jenkins server

2. Which of the following is the correct syntax to add a post-build action in a Jenkins pipeline script?

easy

A. build {
post {
echo 'Build finished'
}
}

B. pipeline {
postbuild {
echo 'Build finished'
}
}

C. steps {
post {
echo 'Build finished'
}
}

D. post {
always {
echo 'Build finished'
}
}

Solution

1. Step 1: Recall Jenkins pipeline post syntax

   In declarative pipelines, post block defines post-build actions with conditions like always.

2. Step 2: Match syntax options

   post { always { echo 'Build finished' } } uses correct post { always { ... } } syntax. Others use invalid blocks like build or postbuild.

3. Final Answer:

   post { always { echo 'Build finished' } } -> Option D

4. Quick Check:

   Post block syntax = post { always { echo 'Build finished' } } [OK]

Hint: Use 'post { always { ... } }' for post-build actions in pipeline [OK]

Common Mistakes:

• Using 'postbuild' instead of 'post'
• Placing post block inside 'steps'
• Using 'build' block incorrectly

3. Given this Jenkins pipeline snippet, what will be printed after the build finishes successfully?

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

medium

A. Building...
Build failed!

B. Building...
Build succeeded!

C. Build succeeded!

D. Build failed!

Solution

1. Step 1: Analyze build steps

   The pipeline prints 'Building...' during the build stage.

2. Step 2: Check post-build actions on success

   On successful build, the success block runs, printing 'Build succeeded!'.

3. Final Answer:

   Building... Build succeeded! -> Option B

4. Quick Check:

   Success post block runs after build [OK]

Hint: Success block runs only if build succeeds [OK]

Common Mistakes:

• Confusing failure block with success block
• Ignoring initial build echo
• Assuming post block runs before build

4. You wrote this Jenkins pipeline post section but the notification never sends on build failure:

post {
  failure {
    mail(to: '[e-mail]', subject: 'Build Failed')
  }
}

What is the likely problem?

medium

A. The mail step requires proper Jenkins email configuration

B. The failure block should be inside steps

C. The mail step requires a steps block inside failure

D. The post block must be inside steps

Solution

1. Step 1: Understand the mail step requirements

   The mail step requires the 'Email Extension Plugin' to be installed and SMTP server configured in Manage Jenkins > Configure System > Extended E-mail Notification.

2. Step 2: Identify the likely problem

   Without proper email configuration (SMTP host, port, credentials, etc.), the notification won't send even if the syntax is correct.

3. Final Answer:

   The mail step requires proper Jenkins email configuration -> Option A

4. Quick Check:

   Mail needs SMTP config [OK]

Hint: Configure SMTP in Jenkins for mail step [OK]

Common Mistakes:

• Not installing Email Extension plugin
• Not setting SMTP server details
• Missing 'from' address or credentials

5. You want to archive build artifacts only if the build succeeds and always send a notification email regardless of build result. Which Jenkins pipeline post section correctly implements this?

hard

A. post {
success {
archiveArtifacts 'build/*.jar'
}
always {
mail(to: '[e-mail]', subject: 'Build Notification')
}
}

B. post {
always {
archiveArtifacts 'build/*.jar'
mail(to: '[e-mail]', subject: 'Build Notification')
}
}

C. post {
success {
archiveArtifacts 'build/*.jar'
mail(to: '[e-mail]', subject: 'Build Notification')
}
}

D. post {
failure {
archiveArtifacts 'build/*.jar'
}
always {
mail(to: '[e-mail]', subject: 'Build Notification')
}
}

Solution

1. Step 1: Identify conditions for each action

   Archiving should happen only on success, so it goes inside success. Email should always send, so it goes inside always.

2. Step 2: Match options with conditions

   post { success { archiveArtifacts 'build/*.jar' } always { mail(to: '[e-mail]', subject: 'Build Notification') } } correctly separates archive in success and mail in always. Others mix conditions incorrectly.

3. Final Answer:

   post { success { archiveArtifacts 'build/*.jar' } always { mail(to: '[e-mail]', subject: 'Build Notification') } } -> Option A

4. Quick Check:

   Use success for archive, always for mail [OK]

Hint: Use 'success' for archive, 'always' for notifications [OK]

Common Mistakes:

• Putting archive in always block
• Sending mail only on success
• Archiving on failure instead of success