Building images in CI pipeline in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of Docker build with cache disabled

What will be the output status of the following command when run in a CI pipeline?

docker build --no-cache -t myapp:latest .

Docker

docker build --no-cache -t myapp:latest .

A Build command is invalid and returns a syntax error.

B Build fails due to missing cache layers.

C Build uses cached layers and completes faster.

D Build completes successfully creating a new image without using any cached layers.

💡 Hint

The --no-cache option forces Docker to ignore cached layers.

Using --no-cache tells Docker to build every step fresh, so no cached layers are used. This ensures the image is built from scratch.

✅ Best Practice

intermediate

Choosing the best base image in CI builds

In a CI pipeline, which base image choice is best to minimize build time and image size for a Node.js application?

A Use the full 'node:latest' image with all tools included.

B Use 'node:alpine' image which is smaller and lightweight.

C Use 'ubuntu:latest' and install Node.js manually during build.

D Use 'scratch' base image with no pre-installed software.

💡 Hint

Smaller base images reduce download and build time in CI.

The 'node:alpine' image is a lightweight version optimized for smaller size and faster builds, ideal for CI pipelines.

❓ Troubleshoot

advanced

Diagnosing Docker build failure in CI

A CI pipeline fails at the Docker build step with the error:

failed to solve with frontend dockerfile.v0: failed to read dockerfile: open /workspace/Dockerfile: no such file or directory

What is the most likely cause?

A The Dockerfile syntax has errors causing parsing failure.

B Docker daemon is not running on the CI server.

C The Dockerfile is missing or not in the build context directory.

D The image tag name is invalid.

💡 Hint

Check the location and presence of the Dockerfile in the repository.

The error indicates Docker cannot find the Dockerfile in the specified build context, usually because it is missing or misplaced.

🔀 Workflow

advanced

Correct order of steps in a CI Docker build pipeline

Arrange the following steps in the correct order for a typical CI pipeline that builds and pushes a Docker image:

A 4, 2, 3, 1

B 4, 3, 2, 1

C 2, 4, 3, 1

D 3, 4, 2, 1

💡 Hint

You need source code before testing and building, and push last.

First checkout code, then run tests to verify correctness, then build the image, and finally push it to the registry.

🧠 Conceptual

expert

Effect of multi-stage builds on CI pipeline efficiency

How do multi-stage Docker builds improve CI pipeline efficiency?

A They reduce the final image size by separating build and runtime stages, speeding up deployment.

B They allow parallel builds of multiple images in one Dockerfile.

C They cache all intermediate layers to speed up rebuilds regardless of changes.

D They automatically push images to multiple registries simultaneously.

💡 Hint

Think about how separating build tools from runtime affects image size.

Multi-stage builds let you use heavy tools in early stages and copy only needed artifacts to the final image, making it smaller and faster to deploy.

Practice

1. What is the main purpose of building Docker images in a CI pipeline?

easy

A. To automate packaging the app for consistent deployment

B. To manually upload files to the server

C. To write application code faster

D. To monitor server health

Solution

1. Step 1: Understand CI pipeline role

   CI pipelines automate tasks like testing and packaging to ensure consistency.

2. Step 2: Identify Docker image purpose

   Docker images package the app and its environment for reliable deployment.

3. Final Answer:

   To automate packaging the app for consistent deployment -> Option A

4. Quick Check:

   CI builds images to package apps consistently [OK]

Hint: CI builds images to package apps consistently [OK]

Common Mistakes:

• Confusing image building with code writing
• Thinking CI uploads files manually
• Mixing deployment with monitoring

2. Which of the following is the correct command to build a Docker image named myapp with tag v1 from the current directory?

easy

A. docker build -t myapp:v1 .

B. docker create -t myapp:v1 .

C. docker run -t myapp:v1 .

D. docker push -t myapp:v1 .

Solution

1. Step 1: Identify Docker build syntax

   The correct syntax to build an image is docker build -t name:tag path.

2. Step 2: Match command to syntax

   docker build -t myapp:v1 . uses docker build -t myapp:v1 . which matches the syntax and current directory.

3. Final Answer:

   docker build -t myapp:v1 . -> Option A

4. Quick Check:

   Build command uses 'docker build -t name:tag path' [OK]

Hint: Use 'docker build -t name:tag path' to build images [OK]

Common Mistakes:

• Using 'docker create' instead of 'docker build'
• Confusing 'docker run' with building images
• Trying to push before building

3. Given this CI script snippet:

docker build -t myapp:latest .
docker tag myapp:latest myapp:build-123

What will be the result after running these commands?

medium

A. An error because tagging must happen before building

B. Only one image named 'myapp:build-123' exists

C. Two images: 'myapp:latest' and 'myapp:build-123' pointing to the same image

D. Two images with different contents

Solution

1. Step 1: Understand docker build output

   The build creates an image tagged 'myapp:latest'.

2. Step 2: Understand docker tag effect

   Tagging 'myapp:latest' as 'myapp:build-123' creates a new tag pointing to the same image.

3. Final Answer:

   Two images: 'myapp:latest' and 'myapp:build-123' pointing to the same image -> Option C

4. Quick Check:

   Tag duplicates image reference, no new image created [OK]

Hint: Tagging duplicates image reference, no new image built [OK]

Common Mistakes:

• Thinking tagging creates a new image
• Assuming error if tag after build
• Believing images have different contents after tag

4. A CI pipeline script has this line:

docker build -t myapp .

But the build fails with error: "Cannot locate Dockerfile". What is the likely cause?

medium

A. The tag name 'myapp' is invalid

B. Dockerfile is missing in the current directory

C. The docker daemon is not running

D. The build command syntax is wrong

Solution

1. Step 1: Analyze error message

   "Cannot locate Dockerfile" means Docker can't find the Dockerfile in the build context.

2. Step 2: Check build context and files

   Since the path is '.', Docker expects a Dockerfile in the current directory, which is missing.

3. Final Answer:

   Dockerfile is missing in the current directory -> Option B

4. Quick Check:

   Missing Dockerfile causes this error [OK]

Hint: Check Dockerfile presence in build directory [OK]

Common Mistakes:

• Blaming tag name for Dockerfile error
• Assuming daemon not running without checking
• Thinking build syntax is incorrect

5. In a CI pipeline, you want to tag Docker images with the build number stored in the environment variable BUILD_ID. Which command correctly builds and tags the image myapp with this dynamic tag?

hard

A. docker build -t 'myapp:${BUILD_ID}' .

B. docker build -t myapp:BUILD_ID .

C. docker build -t myapp:$(BUILD_ID) .

D. docker build -t myapp:$BUILD_ID .

Solution

1. Step 1: Understand shell variable syntax

   In shell scripts, environment variables are accessed with $VAR or ${VAR}.

2. Step 2: Identify correct variable usage in command

   docker build -t myapp:$BUILD_ID . uses $BUILD_ID which is valid and common in CI scripts.

3. Final Answer:

   docker build -t myapp:$BUILD_ID . -> Option D

4. Quick Check:

   Use $VAR to insert env variable in commands [OK]

Hint: Use $VAR to insert env variable in commands [OK]

Common Mistakes:

• Using literal 'BUILD_ID' instead of variable
• Using incorrect syntax like $(BUILD_ID)
• Forgetting to expand variable in tag