Job configuration sections in Jenkins - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is the purpose of the 'General' section in a Jenkins job configuration?

The 'General' section lets you set the basic job details like its description and options such as discarding old builds or allowing concurrent builds.

beginner

What does the 'Source Code Management' section in Jenkins job configuration do?

It defines where Jenkins should get the source code from, like a Git repository URL and credentials, so Jenkins can fetch the code to build.

beginner

Explain the 'Build Triggers' section in Jenkins job configuration.

This section controls when the job should start automatically, such as on a schedule, after another job finishes, or when code changes are detected.

beginner

What is configured in the 'Build' section of a Jenkins job?

The 'Build' section defines the actual steps Jenkins runs to build or test your project, like running shell commands or invoking build tools.

beginner

What is the role of the 'Post-build Actions' section in Jenkins job configuration?

It specifies tasks Jenkins should do after the build finishes, such as sending notifications, archiving artifacts, or triggering other jobs.

Which Jenkins job configuration section is used to specify the Git repository URL?

A Build Triggers

B Source Code Management

C Post-build Actions

D General

The 'Source Code Management' section is where you provide the repository URL and credentials.

Where do you configure automatic job start conditions in Jenkins?

A Build Triggers

B Build

C General

D Post-build Actions

The 'Build Triggers' section controls when Jenkins starts the job automatically.

Which section defines the commands Jenkins runs to build your project?

A Source Code Management

B Post-build Actions

C General

D Build

The 'Build' section contains the steps Jenkins executes to build or test the project.

If you want Jenkins to send an email after a build, which section do you configure?

A Build

B General

C Post-build Actions

D Build Triggers

The 'Post-build Actions' section is for tasks like notifications after the build.

What can you set in the 'General' section of a Jenkins job?

A Job description and options

B Post-build notifications

C Source code repository

D Build steps

The 'General' section lets you set the job's description and basic options.

Describe the main sections of a Jenkins job configuration and their purposes.

Think about the flow from job setup to build to what happens after.

Explain how Jenkins knows when to start a job automatically and where this is configured.

Focus on the section that controls job start timing.

Practice

1. Which section in a Jenkins job configuration is used to divide the process into steps like build, test, and deploy?

easy

A. Triggers

B. Post

C. Environment

D. Stages

Solution

1. Step 1: Understand Jenkins job structure

   Jenkins jobs are organized into sections to manage tasks clearly.

2. Step 2: Identify the section for dividing tasks

   The 'Stages' section splits the job into steps like build, test, and deploy.

3. Final Answer:

   Stages -> Option D

4. Quick Check:

   Stages = Steps division [OK]

Hint: Stages split tasks into steps like build and test [OK]

Common Mistakes:

• Confusing Post section with Stages
• Thinking Environment defines steps
• Mixing Triggers with task division

2. Which of the following is the correct syntax to define a post section in a Jenkins declarative pipeline?

easy

A. post { always { echo 'Done' } }

B. post: { always: { echo 'Done' } }

C. post => { always => { echo 'Done' } }

D. post = { always = { echo 'Done' } }

Solution

1. Step 1: Recall Jenkins declarative syntax

   Jenkins uses braces and keywords without colons or arrows in declarative pipelines.

2. Step 2: Check each option's syntax

   post { always { echo 'Done' } } uses correct braces and keywords: post { always { ... } }.

3. Final Answer:

   post { always { echo 'Done' } } -> Option A

4. Quick Check:

   Correct post syntax uses braces and keywords [OK]

Hint: Use braces and keywords without colons or arrows [OK]

Common Mistakes:

• Using colons instead of braces
• Using arrows => instead of braces
• Assigning with = instead of braces

3. Given this Jenkins pipeline snippet:

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

What will Jenkins print if the build step runs without errors?

medium

A. Build succeeded

B. Building...
Build succeeded

C. Building...
Build failed

D. Build failed

Solution

1. Step 1: Analyze the stages and steps

   The 'Build' stage prints 'Building...'. If no errors occur, it succeeds.

2. Step 2: Check post section behavior

   On success, it prints 'Build succeeded'. On failure, 'Build failed'.

3. Final Answer:

   Building... Build succeeded -> Option B

4. Quick Check:

   Success triggers 'Build succeeded' after build step [OK]

Hint: Success post runs only if build passes [OK]

Common Mistakes:

• Assuming failure message prints on success
• Ignoring the initial build echo
• Confusing post section triggers

4. You wrote this Jenkins pipeline snippet:

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        echo 'Testing...'
      }
    }
  }
  post {
    always echo 'Cleaning up'
  }
}

But Jenkins throws a syntax error. What is the likely cause?

medium

A. Missing braces around the 'always' block

B. Incorrect indentation inside 'stages'

C. Using 'always' inside 'post' without a condition

D. Missing 'steps' block inside 'always'

Solution

1. Step 1: Review 'post' section syntax

   Each condition like 'always' must be followed by braces { ... } containing steps or actions.

2. Step 2: Check the given snippet

   'always echo ...' lacks braces after 'always', causing a syntax error.

3. Final Answer:

   Missing braces around the 'always' block -> Option A

4. Quick Check:

   Post conditions need braces { block } [OK]

Hint: Post conditions like 'always' require { block } [OK]

Common Mistakes:

• Forgetting braces around post condition blocks
• Assuming indentation causes syntax error
• Thinking 'always' needs no condition

5. You want a Jenkins job to run these steps: build, test, and deploy. You also want to send a notification only if the deploy step fails. Which job configuration sections should you use to organize this?

hard

A. Use 'post' for build, test, deploy; use 'stages' with 'failure' for notification

B. Use 'environment' for build, test, deploy; use 'post' with 'always' for notification

C. Use 'stages' for build, test, deploy; use 'post' with 'failure' for notification

D. Use 'triggers' for build, test, deploy; use 'post' with 'success' for notification

Solution

1. Step 1: Organize main tasks

   Use 'stages' section to split the job into build, test, and deploy steps.

2. Step 2: Handle failure notifications

   Use 'post' section with 'failure' condition to send notification if deploy fails.

3. Final Answer:

   Use 'stages' for build, test, deploy; use 'post' with 'failure' for notification -> Option C

4. Quick Check:

   Stages for tasks, post failure for alerts [OK]

Hint: Stages for steps, post failure for alerts [OK]

Common Mistakes:

• Putting main tasks inside post section
• Using post success instead of failure for alerts
• Confusing triggers with task steps