Job configuration sections in Jenkins - Commands & Configuration

Introduction

Jenkins jobs need configuration files to tell them what to do. These files have sections that organize settings like source code location, build steps, and notifications. This helps Jenkins run tasks automatically and correctly.

When you want Jenkins to pull code from a Git repository before building.

When you need to run a script or command as part of your build process.

When you want Jenkins to send an email after a build finishes.

When you want to set environment variables for your build steps.

When you want to schedule your job to run at specific times automatically.

Config File - config.xml

config.xml

<?xml version="1.0" encoding="UTF-8"?>
<project>
  <actions/>
  <description>Example Jenkins job configuration</description>
  <keepDependencies>false</keepDependencies>
  <properties/>
  <scm class="hudson.plugins.git.GitSCM" plugin="git@4.10.0">
    <configVersion>2</configVersion>
    <userRemoteConfigs>
      <hudson.plugins.git.UserRemoteConfig>
        <url>https://github.com/example/my-app.git</url>
      </hudson.plugins.git.UserRemoteConfig>
    </userRemoteConfigs>
    <branches>
      <hudson.plugins.git.BranchSpec>
        <name>*/main</name>
      </hudson.plugins.git.BranchSpec>
    </branches>
    <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations>
    <submoduleCfg class="list"/>
    <extensions/>
  </scm>
  <canRoam>true</canRoam>
  <disabled>false</disabled>
  <blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>
  <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>
  <triggers>
    <hudson.triggers.TimerTrigger>
      <spec>H 2 * * *</spec>
    </hudson.triggers.TimerTrigger>
  </triggers>
  <concurrentBuild>false</concurrentBuild>
  <builders>
    <hudson.tasks.Shell>
      <command>echo "Building the project..."
./build.sh</command>
    </hudson.tasks.Shell>
  </builders>
  <publishers>
    <hudson.tasks.Mailer>
      <recipients>[e-mail]</recipients>
      <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
      <sendToIndividuals>true</sendToIndividuals>
    </hudson.tasks.Mailer>
  </publishers>
  <buildWrappers/>
</project>

<scm> tells Jenkins where to get the source code (Git repo URL and branch).

<triggers> schedules the job to run automatically (here, daily at 2 AM).

<builders> defines the commands Jenkins runs to build the project.

<publishers> sets notifications, like sending emails after builds.

Commands

This command creates a new Jenkins job named 'example-job' using the configuration file 'config.xml'. It tells Jenkins what the job should do.

Terminal

java -jar jenkins-cli.jar -s http://localhost:8080 create-job example-job < config.xml

Expected Output

Created job: example-job

→

-s - Specifies the Jenkins server URL

This command starts a build of the 'example-job' immediately to test if the configuration works.

Terminal

java -jar jenkins-cli.jar -s http://localhost:8080 build example-job

Expected Output

Started build #1 for job example-job

→

-s - Specifies the Jenkins server URL

This command retrieves and shows the current configuration of the 'example-job' to verify it was set correctly.

Terminal

java -jar jenkins-cli.jar -s http://localhost:8080 get-job example-job

Expected Output

<?xml version="1.0" encoding="UTF-8"?>

<project>

  <actions/>

  <description>Example Jenkins job configuration</description>

  <keepDependencies>false</keepDependencies>

  <properties/>

  <scm class="hudson.plugins.git.GitSCM" plugin="git@4.10.0">

    <configVersion>2</configVersion>

    <userRemoteConfigs>

      <hudson.plugins.git.UserRemoteConfig>

        <url>https://github.com/example/my-app.git</url>

      </hudson.plugins.git.UserRemoteConfig>

    </userRemoteConfigs>

    <branches>

      <hudson.plugins.git.BranchSpec>

        <name>*/main</name>

      </hudson.plugins.git.BranchSpec>

    </branches>

    <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations>

    <submoduleCfg class="list"/>

    <extensions/>

  </scm>

  <canRoam>true</canRoam>

  <disabled>false</disabled>

  <blockBuildWhenDownstreamBuilding>false</blockBuildWhenDownstreamBuilding>

  <blockBuildWhenUpstreamBuilding>false</blockBuildWhenUpstreamBuilding>

  <triggers>

    <hudson.triggers.TimerTrigger>

      <spec>H 2 * * *</spec>

    </hudson.triggers.TimerTrigger>

  </triggers>

  <concurrentBuild>false</concurrentBuild>

  <builders>

    <hudson.tasks.Shell>

      <command>echo "Building the project..."

./build.sh</command>

    </hudson.tasks.Shell>

  </builders>

  <publishers>

    <hudson.tasks.Mailer>

      <recipients>[e-mail]</recipients>

      <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>

      <sendToIndividuals>true</sendToIndividuals>

    </hudson.tasks.Mailer>

  </publishers>

  <buildWrappers/>

</project>

→

-s - Specifies the Jenkins server URL

Key Concept

If you remember nothing else from this pattern, remember: Jenkins job configuration sections organize how the job gets code, builds it, runs, and reports results.

Common Mistakes

Forgetting to include the <scm> section or giving a wrong Git URL.

Jenkins won't know where to get the source code, so the build will fail.

Always include a valid <scm> section with the correct repository URL and branch.

Not defining any build steps inside <builders>.

Jenkins will run the job but do nothing, so no build happens.

Add at least one build step like a shell command or script inside <builders>.

Setting an invalid schedule in <triggers>.

The job won't run automatically as expected.

Use valid cron syntax for the <spec> field to schedule builds properly.

Summary

The config.xml file defines sections like <scm>, <builders>, <triggers>, and <publishers> to control job behavior.

Use Jenkins CLI commands to create, build, and check jobs using this configuration file.

Correct configuration ensures Jenkins can get code, build it, schedule runs, and send notifications.

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