GitLab CI comparison in Jenkins - Step-by-Step Execution

Process Flow - GitLab CI comparison

Write Jenkinsfile

↓

Commit to Repo

↓

Jenkins Polls or Webhook Trigger

↓

Jenkins Master Schedules Job

↓

Agent Executes Pipeline Steps

↓

Job Status Reported

↓

Developer Sees Results

↓

Write .gitlab-ci.yml

↓

Commit to Repo

↓

GitLab Detects Commit

↓

GitLab Runner Executes Jobs

↓

Job Status Reported

↓

Developer Sees Results

Shows the step-by-step flow of how Jenkins and GitLab CI pipelines are triggered and executed after code commits.

Execution Sample

Jenkins

pipeline {
  agent any
  stages {
    stage('Build') {
      steps { echo 'Building...' }
    }
  }
}

A simple Jenkins pipeline that runs a build stage printing 'Building...'

Process Table

Step	Action	Trigger	Result	Notes
1	Write Jenkinsfile	Manual	Jenkinsfile created in repo	Defines pipeline steps
2	Commit Jenkinsfile	Developer commit	Code pushed to repo	Triggers Jenkins polling or webhook
3	Jenkins detects commit	Polling/Webhook	Schedules pipeline job	Master assigns job to agent
4	Agent runs 'Build' stage	Job start	Prints 'Building...'	Executes pipeline steps
5	Job completes	Job end	Status reported to Jenkins UI	Success or failure shown
6	Write .gitlab-ci.yml	Manual	.gitlab-ci.yml created	Defines GitLab CI jobs
7	Commit .gitlab-ci.yml	Developer commit	Code pushed to GitLab repo	Triggers GitLab pipeline
8	GitLab detects commit	Push event	Pipeline scheduled	GitLab Runner picks job
9	Runner executes job	Job start	Job runs defined steps	Outputs logs in GitLab UI
10	Job completes	Job end	Status shown in GitLab UI	Success or failure visible
11	Exit	No more steps	Pipeline finished	End of process

💡 Pipeline finishes after all stages/jobs complete and status is reported

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	After Step 7	After Step 9	Final
Jenkinsfile	None	Created	Exists	Exists	Exists	Exists	Exists
.gitlab-ci.yml	None	None	None	None	Created	Exists	Exists
Pipeline Status	None	Pending	Running	Success	Pending	Running	Success

Key Moments - 3 Insights

Why does Jenkins need a separate agent to run jobs?

Jenkins master schedules jobs but agents do the actual work to keep master free for coordination, as shown in execution_table step 3 and 4.

How does GitLab CI detect when to start a pipeline?

GitLab CI automatically detects commits via push events to the repo, triggering pipelines without extra setup, as seen in execution_table step 8.

Can Jenkins and GitLab CI pipelines run on the same repository?

Yes, both can run independently if configured, but they use different config files and runners/agents, shown by separate steps for Jenkinsfile and .gitlab-ci.yml.

Visual Quiz - 3 Questions

Look at the execution table, at which step does Jenkins agent start running the build stage?

A Step 4

B Step 5

C Step 3

D Step 2

💡 Hint

Check the 'Action' and 'Result' columns for when the build stage runs.

According to the variable tracker, what is the pipeline status after step 5?

A Pending

B Running

C Success

D None

💡 Hint

Look at the 'Pipeline Status' row under 'After Step 5' column.

If the .gitlab-ci.yml file is not committed, what happens to the GitLab pipeline?

A Pipeline runs with default settings

B Pipeline is not triggered

C Pipeline runs but fails immediately

D Pipeline triggers Jenkins instead

💡 Hint

Refer to execution_table steps 6 and 7 about .gitlab-ci.yml creation and commit.

Concept Snapshot

GitLab CI and Jenkins both automate code testing and deployment.
Jenkins uses a Jenkinsfile and agents to run pipelines.
GitLab CI uses .gitlab-ci.yml and runners triggered by repo pushes.
Both report job status to developers.
Jenkins requires separate agents; GitLab CI integrates runners.
Choose based on your project needs and environment.

Full Transcript

This visual execution compares Jenkins and GitLab CI pipelines. Jenkins requires writing a Jenkinsfile, committing it, then Jenkins detects the commit via polling or webhook. The master schedules the job, and an agent runs the pipeline steps like 'Build'. The job status is reported back to Jenkins UI. GitLab CI uses a .gitlab-ci.yml file committed to the repo. GitLab detects the commit automatically and schedules the pipeline. GitLab runners execute the jobs and show status in GitLab UI. Variables like pipeline status change from pending to running to success as jobs progress. Key points include Jenkins needing agents to run jobs, GitLab CI triggering pipelines automatically on push, and both systems being able to run on the same repo independently. The quiz checks understanding of when Jenkins agents run, pipeline status changes, and GitLab pipeline triggers. This helps beginners see the step-by-step flow and differences between Jenkins and GitLab CI.

Practice

1. Which statement best describes the main difference between Jenkins and GitLab CI?

easy

A. Jenkins cannot automate building and testing.

B. GitLab CI has more plugins than Jenkins.

C. GitLab CI is easier to start with if you already use GitLab for your code.

D. Jenkins is only for deployment, not for testing.

Solution

1. Step 1: Understand GitLab CI's integration

   GitLab CI is built into GitLab, making it simpler to start if your code is hosted there.

2. Step 2: Compare Jenkins capabilities

   Jenkins offers more flexibility and plugins but requires more setup.

3. Final Answer:

   GitLab CI is easier to start with if you already use GitLab for your code. -> Option C

4. Quick Check:

   GitLab CI simpler start = B [OK]

Hint: GitLab CI is simpler if your code is on GitLab [OK]

Common Mistakes:

• Thinking Jenkins cannot automate testing
• Assuming GitLab CI has more plugins
• Believing Jenkins is only for deployment

2. Which of the following is the correct way to define a simple Jenkins pipeline step that echoes 'Hello World'?

easy

A. pipeline { stages { stage('Example') { steps { echo 'Hello World' } } } }

B. pipeline { steps { stage('Example') { echo 'Hello World' } } }

C. pipeline { stage('Example') { steps { print('Hello World') } } }

D. pipeline { stages { step('Example') { echo 'Hello World' } } }

Solution

1. Step 1: Recall Jenkins pipeline syntax

   A Jenkins pipeline requires 'stages' containing 'stage' blocks, each with 'steps'. The echo command is inside steps.

2. Step 2: Identify correct syntax

   pipeline { stages { stage('Example') { steps { echo 'Hello World' } } } } correctly nests stages, stage, steps, and uses echo properly.

3. Final Answer:

   pipeline { stages { stage('Example') { steps { echo 'Hello World' } } } } -> Option A

4. Quick Check:

   Correct Jenkins pipeline syntax = A [OK]

Hint: Remember stages > stage > steps > commands in Jenkins pipeline [OK]

Common Mistakes:

• Placing steps outside stage
• Using print instead of echo
• Misnaming stage as step

3. Given this Jenkins pipeline snippet, what will be the output in the console?

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        echo 'Building...'
      }
    }
    stage('Test') {
      steps {
        echo 'Testing...'
      }
    }
  }
}

medium

A. Build stage skipped, only Testing runs

B. Building...\nTesting...

C. Testing...\nBuilding...

D. Syntax error, pipeline fails

Solution

1. Step 1: Analyze pipeline stages order

   The pipeline runs stages in order: first 'Build', then 'Test'. Each stage echoes its message.

2. Step 2: Determine console output

   The console will show 'Building...' first, then 'Testing...'.

3. Final Answer:

   Building...\nTesting... -> Option B

4. Quick Check:

   Stages run sequentially = C [OK]

Hint: Jenkins stages run in order, echo outputs in sequence [OK]

Common Mistakes:

• Assuming stages run in parallel by default
• Mixing order of outputs
• Thinking pipeline syntax is invalid

4. You have this Jenkins pipeline snippet:

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        echo 'Building...'
      }
    }
    stage('Test') {
      step {
        echo 'Testing...'
      }
    }
  }
}

What is the problem with this pipeline?

medium

A. The 'Test' stage uses 'step' instead of 'steps', causing a syntax error.

B. The 'Build' stage is missing an agent.

C. The echo command is invalid in Jenkins pipelines.

D. Stages must be defined outside the pipeline block.

Solution

1. Step 1: Check stage syntax

   Each stage must have a 'steps' block, not 'step'. The 'Test' stage incorrectly uses 'step'.

2. Step 2: Understand Jenkins syntax rules

   This causes a syntax error because Jenkins expects 'steps' to group commands.

3. Final Answer:

   The 'Test' stage uses 'step' instead of 'steps', causing a syntax error. -> Option A

4. Quick Check:

   Use 'steps' block in stages = A [OK]

Hint: Stages require 'steps' block, not 'step' [OK]

Common Mistakes:

• Confusing 'step' and 'steps'
• Thinking echo is invalid
• Misplacing stages outside pipeline

5. You want to migrate a simple GitLab CI pipeline to Jenkins. The GitLab CI YAML is:

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building..."

test_job:
  stage: test
  script:
    - echo "Testing..."

Which Jenkins pipeline best replicates this behavior?

hard

A. pipeline {
agent any
stages {
stage('build') {
steps {
print('Building...')
}
}
stage('test') {
steps {
print('Testing...')
}
}
}
}

B. pipeline {
agent any
steps {
echo 'Building...'
echo 'Testing...'
}
}

C. pipeline {
agent any
stages {
stage('build') {
step {
echo 'Building...'
}
}
stage('test') {
step {
echo 'Testing...'
}
}
}
}

D. pipeline {
agent any
stages {
stage('build') {
steps {
echo 'Building...'
}
}
stage('test') {
steps {
echo 'Testing...'
}
}
}
}

Solution

1. Step 1: Map GitLab stages to Jenkins stages

   GitLab stages 'build' and 'test' correspond to Jenkins stages named 'build' and 'test'.

2. Step 2: Use correct Jenkins syntax

   Each stage must have a 'steps' block with echo commands to replicate the script commands.

3. Final Answer:

   Jenkins pipeline with stages 'build' and 'test' each having steps with echo commands. -> Option D

4. Quick Check:

   Match GitLab stages with Jenkins stages and steps = D [OK]

Hint: Translate GitLab stages to Jenkins stages with steps and echo [OK]

Common Mistakes:

• Using 'step' instead of 'steps'
• Using print instead of echo
• Putting all commands in one steps block without stages