Building images in CI pipeline in Docker - Step-by-Step Execution

Process Flow - Building images in CI pipeline

Start CI Pipeline

↓

Checkout Code

↓

Run Docker Build

↓

Build Image

↓

Tag Image

↓

Push Image to Registry

↓

End Pipeline

The CI pipeline starts by getting the code, then builds a Docker image, tags it, and pushes it to a registry.

Execution Sample

Docker

git checkout main

docker build -t myapp:latest .
docker tag myapp:latest registry.example.com/myapp:latest
docker push registry.example.com/myapp:latest

This code checks out the main branch, builds a Docker image, tags it for the registry, and pushes it.

Process Table

Step	Action	Command	Result
1	Checkout code	git checkout main	Code switched to main branch
2	Build Docker image	docker build -t myapp:latest .	Image 'myapp:latest' built successfully
3	Tag image for registry	docker tag myapp:latest registry.example.com/myapp:latest	Image tagged as 'registry.example.com/myapp:latest'
4	Push image to registry	docker push registry.example.com/myapp:latest	Image pushed to registry successfully
5	Pipeline complete	-	Docker image ready in registry

💡 Pipeline ends after image is pushed to the registry

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
Code branch	none	main	main	main	main
Docker image	none	none	myapp:latest	registry.example.com/myapp:latest	registry.example.com/myapp:latest
Registry status	none	none	none	none	pushed

Key Moments - 3 Insights

Why do we tag the image before pushing it?

Tagging the image with the registry address (step 3) tells Docker where to push it. Without tagging, Docker won't know the destination.

What happens if the build fails at step 2?

If the build fails, the pipeline stops and the image is not created or pushed. This prevents pushing broken images.

Why do we checkout the code first?

Checking out the code (step 1) ensures the latest source files are used to build the image, so the image matches the current code.

Visual Quiz - 3 Questions

Look at the execution table, what is the Docker image name after step 2?

A registry.example.com/myapp:latest

B none

C myapp:latest

D main

💡 Hint

Check the 'Docker image' variable in variable_tracker after Step 2

At which step is the image pushed to the registry?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look at the 'Action' and 'Result' columns in the execution_table

If the code checkout fails at step 1, what happens next?

A The pipeline continues to build the image

B The pipeline stops and no image is built

C The image is tagged but not pushed

D The image is pushed without building

💡 Hint

Refer to key_moments about build failure and pipeline stopping

Concept Snapshot

Building images in CI pipeline:
1. Checkout code to get latest files
2. Build Docker image locally
3. Tag image with registry path
4. Push image to remote registry
5. Pipeline ends with image ready for deployment

Full Transcript

In a CI pipeline for building Docker images, the process starts by checking out the latest code from the repository. Then, the pipeline runs the docker build command to create an image from the Dockerfile and source code. After the image is built, it is tagged with the registry address so Docker knows where to push it. Finally, the image is pushed to the remote registry, making it available for deployment. If any step fails, the pipeline stops to avoid pushing incomplete or broken images.

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