CircleCI comparison in Jenkins - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is CircleCI?

CircleCI is a cloud-based continuous integration and continuous delivery (CI/CD) platform that automates software testing and deployment.

beginner

How does CircleCI differ from Jenkins in terms of setup?

CircleCI is cloud-hosted and requires minimal setup, while Jenkins is self-hosted and needs manual installation and configuration.

intermediate

What is a key advantage of Jenkins over CircleCI?

Jenkins offers more customization and plugin options because it is open-source and self-hosted, allowing full control over the environment.

intermediate

How does CircleCI handle scaling compared to Jenkins?

CircleCI automatically scales build resources in the cloud, while Jenkins requires manual setup of additional servers or agents for scaling.

beginner

Which tool provides better integration with GitHub and Bitbucket out of the box?

CircleCI provides seamless integration with GitHub and Bitbucket, making it easier to trigger builds on code changes.

Which CI/CD tool is primarily cloud-hosted and requires less manual setup?

A Jenkins

B Travis CI

C CircleCI

D GitLab CI

CircleCI is cloud-hosted and easy to set up, unlike Jenkins which is self-hosted.

What is a main benefit of Jenkins compared to CircleCI?

A Built-in GitHub integration

B Automatic scaling

C Cloud hosting

D More customization and plugins

Jenkins offers more customization and plugins because it is open-source and self-hosted.

How does CircleCI handle build resource scaling?

A Automatic cloud scaling

B Manual server setup

C No scaling support

D Requires third-party tools

CircleCI automatically scales build resources in the cloud.

Which tool requires manual installation and configuration?

A Jenkins

B GitHub Actions

C CircleCI

D Bitbucket Pipelines

Jenkins is self-hosted and requires manual installation and setup.

Which CI/CD tool integrates seamlessly with GitHub and Bitbucket?

A Jenkins

B CircleCI

C Bamboo

D TeamCity

CircleCI provides easy integration with GitHub and Bitbucket.

Explain the main differences between CircleCI and Jenkins in terms of setup, scaling, and customization.

Think about where each tool runs and how much control you have.

Describe why a team might choose CircleCI over Jenkins for their CI/CD pipeline.

Consider convenience and cloud features.

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