Source code management setup in Jenkins - Commands & Configuration

Introduction

Source code management setup in Jenkins helps you connect your Jenkins jobs to your code repositories. This lets Jenkins automatically get your code to build, test, and deploy it without manual copying.

When you want Jenkins to automatically pull the latest code from GitHub for building.

When you need to trigger Jenkins jobs after code changes in a repository.

When you want to keep your build process connected to your version control system.

When you want to manage multiple branches or repositories in Jenkins jobs.

When you want to track which code version was used for each build.

Config File - Jenkinsfile

Jenkinsfile

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git url: 'https://github.com/example-user/example-repo.git', branch: 'main'
            }
        }
        stage('Build') {
            steps {
                echo 'Building the project...'
            }
        }
    }
}

This Jenkinsfile defines a pipeline with two stages: Checkout and Build.

The git step in the Checkout stage connects Jenkins to the GitHub repository URL and checks out the main branch.

This setup ensures Jenkins pulls the latest code before building.

Commands

This command updates or creates a Jenkins job using the job configuration file. It applies the source code management settings defined in the job config.

Terminal

jenkins-jobs --conf jenkins.ini update example-job.yaml

Expected Output

Job example-job updated successfully

→

--conf - Specifies the Jenkins server configuration file

This command triggers the Jenkins job named 'example-job' to start a build using the configured source code repository.

Terminal

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

Expected Output

Started build #1

→

-s - Specifies the Jenkins server URL

This command shows the console output of build number 1 for the job 'example-job' to verify the source code was checked out and build started.

Terminal

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

Expected Output

[Pipeline] Start of Pipeline

[Pipeline] git

Fetching changes from the remote Git repository

[Pipeline] echo

Building the project...

[Pipeline] End of Pipeline

Finished: SUCCESS

→

-s - Specifies the Jenkins server URL

Key Concept

If you remember nothing else from this pattern, remember: Jenkins needs a source code repository URL and branch configured to pull your code automatically before building.

Common Mistakes

Not specifying the correct repository URL in the Jenkinsfile or job config.

Jenkins cannot find the code to build and the job fails at checkout.

Always double-check the repository URL and branch name are correct and accessible.

Forgetting to trigger the Jenkins job after setting up source code management.

No build happens, so code changes are not tested or deployed.

Run the build command or configure automatic triggers to start builds on code changes.

Using an incorrect or missing Jenkins server URL in CLI commands.

CLI commands fail to connect to Jenkins and cannot control jobs.

Use the correct Jenkins server URL with the -s flag in CLI commands.

Summary

Configure the Jenkinsfile with the git repository URL and branch to enable code checkout.

Use Jenkins CLI commands to update jobs and trigger builds connected to source code.

Check build console output to verify Jenkins successfully pulled the code and started the build.

Practice

1. What is the main purpose of setting up source code management (SCM) in Jenkins?

easy

A. To automatically fetch the latest code from a repository

B. To manually upload code files to Jenkins

C. To create user accounts for Jenkins

D. To monitor server hardware status

Solution

1. Step 1: Understand SCM role in Jenkins

   SCM connects Jenkins to your code repository to get the latest code automatically.

2. Step 2: Compare options

   Only To automatically fetch the latest code from a repository describes automatic fetching of code, which is the main purpose of SCM setup.

3. Final Answer:

   To automatically fetch the latest code from a repository -> Option A

4. Quick Check:

   SCM = automatic code fetch [OK]

Hint: SCM means Jenkins pulls code automatically [OK]

Common Mistakes:

• Thinking SCM uploads code manually
• Confusing SCM with user management
• Assuming SCM monitors hardware

2. Which Jenkins pipeline syntax correctly checks out code from a Git repository URL https://github.com/example/repo.git on branch main?

easy

A. git url: 'https://github.com/example/repo.git' branch: 'main'

B. checkout([$class: 'GitSCM', branches: [[name: 'main']], userRemoteConfigs: [[url: 'https://github.com/example/repo.git']]])

C. checkout scm: 'https://github.com/example/repo.git', branch: 'main'

D. gitCheckout('https://github.com/example/repo.git', 'main')

Solution

1. Step 1: Recall Jenkins pipeline checkout syntax

   The correct syntax uses checkout with a map specifying $class: 'GitSCM', branches, and userRemoteConfigs.

2. Step 2: Validate options

   checkout([$class: 'GitSCM', branches: [[name: 'main']], userRemoteConfigs: [[url: 'https://github.com/example/repo.git']]]) matches the correct syntax. Options B, C, and D are incorrect Jenkins pipeline syntax.

3. Final Answer:

   checkout([$class: 'GitSCM', branches: [[name: 'main']], userRemoteConfigs: [[url: 'https://github.com/example/repo.git']]]) -> Option B

4. Quick Check:

   Use checkout with GitSCM map [OK]

Hint: Use checkout with $class: 'GitSCM' for Git repos [OK]

Common Mistakes:

• Using incorrect method names like gitCheckout
• Missing $class: 'GitSCM' in checkout
• Wrong parameter names or structure

3. Given this Jenkins pipeline snippet, what will be the output if the repository URL is invalid?

pipeline {
  agent any
  stages {
    stage('Checkout') {
      steps {
        checkout([$class: 'GitSCM', branches: [[name: 'main']], userRemoteConfigs: [[url: 'https://invalid-url/repo.git']]])
      }
    }
  }
}

medium

A. The pipeline will retry checkout indefinitely

B. The pipeline will succeed but skip checkout

C. The pipeline will fail with a checkout error

D. The pipeline will ignore the invalid URL and continue

Solution

1. Step 1: Understand checkout behavior with invalid URL

   If the Git URL is invalid, Jenkins cannot fetch code and throws an error causing the pipeline to fail.

2. Step 2: Analyze options

   Only The pipeline will fail with a checkout error correctly states the pipeline fails with a checkout error. Others describe incorrect behaviors.

3. Final Answer:

   The pipeline will fail with a checkout error -> Option C

4. Quick Check:

   Invalid URL causes checkout failure [OK]

Hint: Invalid repo URL causes pipeline failure [OK]

Common Mistakes:

• Assuming pipeline skips checkout silently
• Thinking Jenkins retries forever
• Believing pipeline ignores errors

4. You wrote this Jenkins pipeline snippet to checkout code but it fails with a syntax error:

checkout([$class: 'GitSCM', branches: [name: 'main'], userRemoteConfigs: [[url: 'https://github.com/example/repo.git']]])

What is the error and how to fix it?

medium

A. Missing quotes around $class; fix to "$class: 'GitSCM'"

B. Wrong URL format; fix to '[e-mail]:example/repo.git'

C. Incorrect method name; fix to gitCheckout(...)

D. Missing double brackets around branches list; fix to branches: [[name: 'main']]

Solution

1. Step 1: Identify syntax error in branches parameter

   The branches parameter expects a list of maps, so it must be double bracketed: [[name: 'main']].

2. Step 2: Correct the branches syntax

   Change branches: [name: 'main'] to branches: [[name: 'main']] to fix the syntax error.

3. Final Answer:

   Missing double brackets around branches list; fix to branches: [[name: 'main']] -> Option D

4. Quick Check:

   Branches list needs double brackets [OK]

Hint: Branches must be a list of maps with double brackets [OK]

Common Mistakes:

• Using single brackets for branches list
• Changing URL format unnecessarily
• Misquoting $class key

5. You want Jenkins to checkout code from a Git repository and only build when the develop branch changes. Which setup correctly achieves this in a declarative pipeline?

hard

A. pipeline {
agent any
triggers {
pollSCM('H/5 * * * *')
}
stages {
stage('Checkout') {
steps {
git branch: 'develop', url: 'https://github.com/example/repo.git'
}
}
}
}

B. pipeline {
agent any
triggers {
pollSCM('H/5 * * * *')
}
stages {
stage('Checkout') {
steps {
checkout([$class: 'GitSCM', branches: [[name: 'main']], userRemoteConfigs: [[url: 'https://github.com/example/repo.git']]])
}
}
}
}

C. pipeline {
agent any
triggers {
cron('H/5 * * * *')
}
stages {
stage('Checkout') {
steps {
checkout([$class: 'GitSCM', branches: [[name: 'develop']], userRemoteConfigs: [[url: 'https://github.com/example/repo.git']]])
}
}
}
}

D. >erp/<}
}
}
}
)]]]'tig.oper/elpmaxe/moc.buhtig//:sptth' :lru[[ :sgifnoCetomeRresu ,]]'niam' :eman[[ :sehcnarb ,'MCStiG' :ssalc$[(tuokcehc
{ spets
{ )'tuokcehC'(egats
{ segats
}
)'* * * * 5/H'(MCSllop
{ sreggirt
yna tnega
{ enilepip>erp<

Solution

1. Step 1: Understand trigger and checkout requirements

   To build only when the develop branch changes, use pollSCM trigger and checkout the develop branch.

2. Step 2: Compare checkout methods

   pipeline {
     agent any
     triggers {
       pollSCM('H/5 * * * *')
     }
     stages {
       stage('Checkout') {
         steps {
           git branch: 'develop', url: 'https://github.com/example/repo.git'
         }
       }
     }
   }

   uses the simpler git step with branch and URL, which works well with pollSCM trigger to watch develop branch changes.

3. Step 3: Identify why others are incorrect

   Options A and C use checkout with GitSCM but C uses cron trigger (not SCM polling).

   pipeline {
     agent any
     triggers {
       pollSCM('H/5 * * * *')
     }
     stages {
       stage('Checkout') {
         steps {
           checkout([$class: 'GitSCM', branches: [[name: 'main']], userRemoteConfigs: [[url: 'https://github.com/example/repo.git']]])
         }
       }
     }
   }

   checks out main branch, not develop.

4. Final Answer:

   Use pollSCM trigger with git step for develop branch checkout -> Option A

5. Quick Check:

   pollSCM + git step + develop branch = correct setup [OK]

Hint: Use pollSCM trigger and git step with branch name [OK]

Common Mistakes:

• Using cron instead of pollSCM for SCM changes
• Checking out wrong branch
• Using complex checkout syntax unnecessarily