CircleCI comparison in Jenkins - Step-by-Step Execution

Process Flow - CircleCI comparison

Start: Code pushed to repo

↓

Trigger CI pipeline

↓

Build, Test, Deploy steps

↓

Feedback: Success or Fail

↓

End

Shows the flow of code triggering a CircleCI pipeline, running build/test/deploy steps, and giving feedback.

Execution Sample

Jenkins

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

A simple Jenkins pipeline that echoes 'Building...' in the build stage.

Process Table

Step	Action	CircleCI Behavior	Jenkins Behavior	Result
1	Code pushed to repo	Triggers CircleCI pipeline automatically	Triggers Jenkins pipeline if webhook configured	Pipeline starts
2	Pipeline config read	Reads .circleci/config.yml	Reads Jenkinsfile in repo	Pipeline config loaded
3	Job execution	Runs jobs in containers or VMs, supports parallelism	Runs jobs on configured agents, parallelism possible but manual	Jobs start
4	Build step	Runs build commands as defined	Runs build commands as defined	Build runs
5	Test step	Runs tests, reports results	Runs tests, reports results	Tests run
6	Deploy step	Deploys if configured, supports workflows	Deploys if scripted, supports pipelines	Deploy runs
7	Feedback	Sends status to VCS, dashboard updates	Sends status to VCS, dashboard updates	User notified
8	Pipeline end	Pipeline finishes, resources released	Pipeline finishes, agents freed	Pipeline complete

💡 Pipeline completes after all configured steps run and feedback is sent.

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
Pipeline Status	Not started	Config loaded	Build running	Deploy running	Complete
Jobs Running	0	0	1 (build)	1 (deploy)	0
Feedback Sent	No	No	No	No	Yes

Key Moments - 3 Insights

Why does CircleCI use a YAML file while Jenkins uses a Jenkinsfile?

CircleCI uses a YAML file (.circleci/config.yml) for pipeline config which is declarative and easy to read, while Jenkins uses a Jenkinsfile written in Groovy script, which is more flexible but requires scripting knowledge. See execution_table step 2.

How does parallel job execution differ between CircleCI and Jenkins?

CircleCI natively supports parallel jobs with simple config, running jobs in isolated containers or VMs. Jenkins can run parallel jobs but requires manual setup of agents and pipeline syntax. See execution_table step 3.

How is feedback delivered to developers in both tools?

Both CircleCI and Jenkins send build status back to the version control system and update their dashboards to notify users of success or failure. See execution_table step 7.

Visual Quiz - 3 Questions

Look at the execution table, at which step does CircleCI read its pipeline configuration?

A Step 1

B Step 4

C Step 2

D Step 7

💡 Hint

Check the 'Pipeline config read' row in the execution_table.

According to the variable tracker, what is the 'Pipeline Status' after Step 4?

A Build running

B Config loaded

C Not started

D Complete

💡 Hint

Look at the 'Pipeline Status' row under 'After Step 4' in variable_tracker.

If Jenkins did not have configured agents, how would the 'Jobs Running' variable change after Step 4?

A It would be 1 as usual

B It would remain 0 because no jobs can run

C It would be 2 because jobs queue up

D It would be -1 indicating error

💡 Hint

Consider the 'Jobs Running' variable and how Jenkins requires agents to run jobs.

Concept Snapshot

CircleCI uses a YAML config file (.circleci/config.yml) to define pipelines declaratively.
Jenkins uses a scripted Jenkinsfile for pipeline definition.
CircleCI runs jobs in containers with easy parallelism.
Jenkins requires manual agent setup for parallel jobs.
Both provide feedback to developers via VCS and dashboards.
CircleCI is cloud-friendly; Jenkins can be self-hosted or cloud.

Full Transcript

This visual execution compares CircleCI and Jenkins pipelines. When code is pushed, both trigger pipelines if configured. CircleCI reads its YAML config file, Jenkins reads the Jenkinsfile script. CircleCI runs jobs in containers with built-in parallelism; Jenkins runs jobs on agents which must be set up. Both run build, test, and deploy steps and send feedback to developers via version control and dashboards. The pipeline ends after all steps complete and feedback is sent. Key differences include config format, parallel job handling, and hosting options.

Practice

1. Which statement best describes Jenkins compared to CircleCI?

easy

A. Jenkins is self-hosted and offers full control over the environment.

B. Jenkins is only cloud-based and easy to start with.

C. Jenkins does not support automation of builds and tests.

D. Jenkins requires no setup or management.

Solution

1. Step 1: Understand Jenkins hosting model

   Jenkins is known for being self-hosted, meaning you install and manage it yourself.

2. Step 2: Compare with CircleCI

   CircleCI is mostly cloud-based and easier to start with, unlike Jenkins which requires more setup.

3. Final Answer:

   Jenkins is self-hosted and offers full control over the environment. -> Option A

4. Quick Check:

   Jenkins = self-hosted, full control [OK]

Hint: Remember Jenkins = self-hosted control, CircleCI = cloud ease [OK]

Common Mistakes:

• Thinking Jenkins is only cloud-based
• Believing Jenkins requires no setup
• Assuming Jenkins can't automate builds

2. Which Jenkins pipeline syntax is correct for a simple build step?

easy

A. pipeline { stages { stage('Build') { run { sh 'make' } } } }

B. pipeline { build { stage('Build') { steps { sh 'make' } } } }

C. pipeline { stages { step('Build') { sh 'make' } } }

D. pipeline { stages { stage('Build') { steps { sh 'make' } } } }

Solution

1. Step 1: Identify correct pipeline block structure

   Jenkins pipelines use 'pipeline' with 'stages', each containing 'stage' and 'steps'.

2. Step 2: Check syntax for build step

   The correct syntax uses 'stage' with 'steps' and inside 'steps' the shell command with 'sh'.

3. Final Answer:

   pipeline { stages { stage('Build') { steps { sh 'make' } } } } -> Option D

4. Quick Check:

   Correct pipeline syntax = pipeline { stages { stage('Build') { steps { sh 'make' } } } } [OK]

Hint: Remember stages contain stage blocks with steps inside [OK]

Common Mistakes:

• Using 'build' instead of 'stages'
• Replacing 'stage' with 'step'
• Using 'run' instead of 'steps'

3. Given this Jenkins pipeline snippet, what will be the output if the shell command fails?

pipeline {
  agent any
  stages {
    stage('Test') {
      steps {
        sh 'exit 1'
      }
    }
  }
}

medium

A. The pipeline will succeed because 'exit 1' is ignored.

B. The pipeline will continue to the next stage ignoring the failure.

C. The pipeline will fail and stop at the 'Test' stage.

D. The pipeline will retry the 'Test' stage automatically.

Solution

1. Step 1: Understand shell command exit codes in Jenkins

   In Jenkins, a shell command returning non-zero exit code causes the stage to fail.

2. Step 2: Analyze the pipeline behavior on failure

   The 'sh' step with 'exit 1' returns failure, so the pipeline stops at 'Test' stage.

3. Final Answer:

   The pipeline will fail and stop at the 'Test' stage. -> Option C

4. Quick Check:

   Non-zero exit code = pipeline failure [OK]

Hint: Non-zero shell exit stops Jenkins pipeline [OK]

Common Mistakes:

• Assuming pipeline continues after failure
• Thinking Jenkins ignores shell exit codes
• Believing Jenkins retries automatically

4. You have a Jenkinsfile with this snippet:

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        sh 'make build'
      }
    }
  }
}

The build step fails but Jenkins shows success. What is the likely cause?

medium

A. The 'make build' command always returns zero exit code.

B. The 'sh' step uses 'returnStatus: true' but the status is not checked to detect failure.

C. The pipeline is configured to ignore all errors globally.

D. The 'sh' step is running in background and not waiting for completion.

Solution

1. Step 1: Understand Jenkins 'sh' step behavior

   By default, 'sh' fails the build if the command returns non-zero exit code unless 'returnStatus: true' is used to handle it manually.

2. Step 2: Identify why failure is ignored

   If 'returnStatus: true' is used but failure is ignored, likely the status is not checked to detect failure.

3. Final Answer:

   The 'sh' step uses 'returnStatus: true' but the status is not checked to detect failure. -> Option B

4. Quick Check:

   Missing returnStatus check causes unnoticed failures [OK]

Hint: Check 'returnStatus' to catch shell errors in Jenkins [OK]

Common Mistakes:

• Assuming shell commands run in background
• Believing Jenkins ignores errors by default
• Thinking 'make build' always succeeds

5. You want to migrate a simple CircleCI config to Jenkins. CircleCI config uses:

version: 2.1
jobs:
  build:
    docker:
      - image: cimg/python:3.8
    steps:
      - checkout
      - run: python -m unittest discover
workflows:
  build_and_test:
    jobs:
      - build

Which Jenkins pipeline snippet best replicates this?

hard

A. pipeline {
agent {
docker { image 'cimg/python:3.8' }
}
stages {
stage('Checkout') {
steps { checkout scm }
}
stage('Test') {
steps { sh 'python -m unittest discover' }
}
}
}

B. pipeline {
agent any
stages {
stage('Build') {
steps { sh 'docker run cimg/python:3.8 python -m unittest discover' }
}
}
}

C. pipeline {
agent {
label 'docker'
}
stages {
stage('Test') {
steps { sh 'python -m unittest discover' }
}
}
}

D. pipeline {
agent none
stages {
stage('Build') {
steps { sh 'python -m unittest discover' }
}
}
}

Solution

1. Step 1: Map CircleCI docker image to Jenkins agent

   CircleCI uses a docker image for the job; Jenkins can specify a docker agent with the same image.

2. Step 2: Replicate steps: checkout and run tests

   Jenkins needs a 'checkout scm' step and a shell command to run tests, matching CircleCI steps.

3. Final Answer:

   pipeline { agent { docker { image 'cimg/python:3.8' } } stages { stage('Checkout') { steps { checkout scm } } stage('Test') { steps { sh 'python -m unittest discover' } } } } -> Option A

4. Quick Check:

   Docker agent + checkout + test command = pipeline { agent { docker { image 'cimg/python:3.8' } } stages { stage('Checkout') { steps { checkout scm } } stage('Test') { steps { sh 'python -m unittest discover' } } } } [OK]

Hint: Use docker agent and separate checkout, test stages [OK]

Common Mistakes:

• Running docker inside shell instead of agent
• Missing checkout step
• Using agent none or wrong label