Docker Pipeline plugin in Jenkins - Time & Space Complexity

Time Complexity: Docker Pipeline plugin

O(n)

Understanding Time Complexity

We want to understand how the time taken by a Jenkins pipeline using the Docker Pipeline plugin changes as we add more steps or containers.

Specifically, how does the number of Docker operations affect the total execution time?

Scenario Under Consideration

Analyze the time complexity of the following Jenkins pipeline snippet using the Docker Pipeline plugin.

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        script {
          docker.image('maven:3.6.3-jdk-11').inside {
            sh 'mvn clean install'
          }
        }
      }
    }
  }
}

This pipeline runs a Maven build inside a Docker container using the Docker Pipeline plugin.

Identify Repeating Operations

Look for repeated actions that take time.

• Primary operation: Starting and stopping the Docker container for the build.
• How many times: Once per pipeline run in this example, but could be multiple if repeated in loops or multiple stages.

How Execution Grows With Input

As the number of Docker container runs increases, the total time grows roughly in direct proportion.

Input Size (number of container runs)	Approx. Operations (container start/stop)
1	1 container start + 1 container stop
10	10 container starts + 10 container stops
100	100 container starts + 100 container stops

Pattern observation: Each additional container run adds a fixed amount of work, so time grows linearly.

Final Time Complexity

Time Complexity: O(n)

This means the total time grows linearly with the number of Docker container runs in the pipeline.

Common Mistake

[X] Wrong: "Starting a Docker container inside the pipeline is instant and does not affect time much."

[OK] Correct: Starting and stopping containers takes noticeable time, so more container runs add up and increase total pipeline time.

Interview Connect

Understanding how pipeline steps scale with input helps you design efficient CI/CD workflows and explain your reasoning clearly in interviews.

Self-Check

"What if we reused a single Docker container for multiple build steps instead of starting a new one each time? How would the time complexity change?"

Practice

1. What is the primary purpose of the docker.build() method in Jenkins Docker Pipeline plugin?

easy

A. To remove unused Docker images

B. To run a Docker container interactively

C. To build a Docker image from a Dockerfile

D. To push a Docker image to a registry

Solution

1. Step 1: Understand the role of docker.build()

   This method is used to create a Docker image from a Dockerfile in the workspace.

2. Step 2: Differentiate from other Docker Pipeline methods

   Running containers uses docker.image().inside { }, pushing uses docker.withRegistry(), and removing images is not handled by docker.build().

3. Final Answer:

   To build a Docker image from a Dockerfile -> Option C

4. Quick Check:

   docker.build() builds images [OK]

Hint: Remember: build = create image from Dockerfile [OK]

Common Mistakes:

• Confusing build with push or run commands
• Thinking docker.build() runs containers
• Assuming it handles image removal

2. Which of the following is the correct syntax to run commands inside a Docker container in a Jenkins pipeline?

easy

A. docker.image('myimage').inside { sh 'echo Hello' }

B. docker.build('myimage') { sh 'echo Hello' }

C. docker.run('myimage') { sh 'echo Hello' }

D. docker.container('myimage').exec { sh 'echo Hello' }

Solution

1. Step 1: Identify the correct method to run commands inside a container

   The docker.image('myimage').inside { } syntax runs commands inside a container created from the image.

2. Step 2: Check other options for syntax errors or misuse

   docker.run() and docker.container() are not valid Jenkins Pipeline methods; docker.build() builds images but does not run containers.

3. Final Answer:

   docker.image('myimage').inside { sh 'echo Hello' } -> Option A

4. Quick Check:

   Use docker.image().inside { } to run commands [OK]

Hint: Use docker.image().inside { } to run commands inside containers [OK]

Common Mistakes:

• Using docker.build() to run commands
• Trying to use non-existent methods like docker.run()
• Confusing image build and container run syntax

3. Given the following Jenkins pipeline snippet, what will be the output of the sh command inside the container?

def img = docker.build('myapp:latest')
img.inside {
  sh 'echo Hello from Docker'
}

medium

A. Error: No such image 'myapp:latest'

B. Hello from Docker

C. Build logs of the Docker image

D. Nothing, the command is not executed

Solution

1. Step 1: Understand the build and run sequence

   The docker.build('myapp:latest') creates the image, then img.inside { } runs commands inside a container from that image.

2. Step 2: Analyze the sh command inside the container

   The shell command echo Hello from Docker runs inside the container and outputs the string.

3. Final Answer:

   Hello from Docker -> Option B

4. Quick Check:

   Commands inside img.inside { } run and output normally [OK]

Hint: Commands inside img.inside { } run inside container [OK]

Common Mistakes:

• Assuming build only creates logs, not image
• Thinking the command runs outside the container
• Expecting an error if image was just built

4. Identify the error in this Jenkins pipeline snippet using Docker Pipeline plugin:

docker.withRegistry('https://myregistry.com', 'my-credentials') {
  def img = docker.build('myapp')
  img.push()
}
img.inside {
  sh 'echo Running inside container'
}

medium

A. The img.push() should be called before docker.withRegistry

B. The docker.build method is missing the Dockerfile path

C. The credentials ID 'my-credentials' is invalid syntax

D. The img.inside block is outside the docker.withRegistry block and will fail

Solution

1. Step 1: Check scope of img variable

   The variable img is defined inside the docker.withRegistry block, so it is not accessible outside that block.

2. Step 2: Identify the error with img.inside usage

   Using img.inside outside the block where img is defined causes a runtime error because img is undefined there.

3. Final Answer:

   The img.inside block is outside the docker.withRegistry block and will fail -> Option D

4. Quick Check:

   Variable scope matters in Jenkins pipeline blocks [OK]

Hint: Keep variable usage inside the block where it's defined [OK]

Common Mistakes:

• Assuming variables are global across blocks
• Confusing credentials ID syntax
• Thinking push must be outside withRegistry

5. You want to build a Docker image, run tests inside a container from that image, and then push the image to a private registry using Jenkins Docker Pipeline plugin. Which pipeline snippet correctly implements this workflow?

hard

A. def img = docker.build('myapp:test')
img.inside {
sh 'run-tests.sh'
}
docker.withRegistry('https://registry.example.com', 'creds') {
img.push()
}

B. docker.withRegistry('https://registry.example.com', 'creds') {
def img = docker.build('myapp:test')
img.push()
img.inside {
sh 'run-tests.sh'
}
}

C. docker.withRegistry('https://registry.example.com', 'creds') {
img.push()
def img = docker.build('myapp:test')
img.inside {
sh 'run-tests.sh'
}
}

D. def img = docker.build('myapp:test')
docker.withRegistry('https://registry.example.com', 'creds') {
img.push()
}
img.inside {
sh 'run-tests.sh'
}

Solution

1. Step 1: Build image and run tests inside container first

   The image must be built before running tests inside it, so docker.build() and img.inside { } come first.

2. Step 2: Push image inside docker.withRegistry() block after tests

   Pushing requires registry credentials, so img.push() must be inside docker.withRegistry() block after tests pass.

3. Step 3: Verify variable scope and order

   def img = docker.build('myapp:test') img.inside { sh 'run-tests.sh' } docker.withRegistry('https://registry.example.com', 'creds') { img.push() } correctly builds image, runs tests inside container, then pushes image with credentials in proper order and scope.

4. Final Answer:

   def img = docker.build('myapp:test') img.inside { sh 'run-tests.sh' } docker.withRegistry('https://registry.example.com', 'creds') { img.push() } -> Option A

5. Quick Check:

   Build -> Test inside container -> Push with credentials [OK]

Hint: Build first, test inside container, then push inside withRegistry [OK]

Common Mistakes:

• Pushing image before running tests
• Using img.inside after pushing outside scope
• Defining variables inside wrong blocks