GitLab CI basics - Step-by-Step Execution

Process Flow - GitLab CI basics

Push code to GitLab repo

↓

GitLab detects push event

↓

GitLab CI reads .gitlab-ci.yml

↓

Pipeline starts: jobs run in stages

↓

Jobs execute scripts on runners

↓

Jobs report success or failure

↓

Pipeline finishes with overall status

This flow shows how pushing code triggers GitLab CI to run jobs defined in the .gitlab-ci.yml file, executing them step-by-step and reporting results.

Execution Sample

Git

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building..."
test_job:
  stage: test
  script:
    - echo "Testing..."

This simple GitLab CI config defines two stages: build and test, each with one job that prints a message.

Process Table

Step	Action	Job	Stage	Script Run	Job Status	Pipeline Status
1	Push code to repo	-	-	-	-	pending
2	GitLab detects push	-	-	-	-	pending
3	Start pipeline	-	-	-	-	running
4	Run build_job	build_job	build	echo "Building..."	success	running
5	Run test_job	test_job	test	echo "Testing..."	success	success

💡 All jobs completed successfully, pipeline status is success.

Status Tracker

Variable	Start	After Step 4	After Step 5	Final
Pipeline Status	pending	running	success	success
build_job Status	not started	success	success	success
test_job Status	not started	not started	success	success

Key Moments - 3 Insights

Why does the pipeline status change from 'pending' to 'running' before jobs start?

The pipeline status changes to 'running' as soon as GitLab starts executing jobs (see step 3 in execution_table). This means the pipeline is active even if no job has finished yet.

What happens if a job fails? Does the pipeline continue?

If a job fails, the pipeline status becomes 'failed' and subsequent jobs in later stages do not run. This is shown by the job status and pipeline status columns in the execution_table.

Why do jobs run in the order of stages?

Jobs run stage by stage to ensure dependencies. In the example, 'build' stage runs before 'test' stage (see 'Stage' column in execution_table). This order is defined in the 'stages' list in the config.

Visual Quiz - 3 Questions

Look at the execution table, what is the pipeline status after step 4?

A success

B running

C pending

D failed

💡 Hint

Check the 'Pipeline Status' column at step 4 in the execution_table.

At which step does the 'test_job' start running?

A Step 5

B Step 4

C Step 3

D Step 2

💡 Hint

Look at the 'Job' and 'Step' columns in the execution_table to find when 'test_job' runs.

If the 'build_job' fails, what will happen to the pipeline status?

A It will remain 'pending'

B It will become 'success'

C It will become 'failed'

D It will skip to 'test' stage

💡 Hint

Refer to the key_moments explanation about job failure impact on pipeline status.

Concept Snapshot

GitLab CI basics:
- Push code triggers pipeline
- .gitlab-ci.yml defines stages and jobs
- Jobs run in stage order
- Each job runs scripts on runners
- Pipeline status reflects job results
- Failure stops later jobs

Full Transcript

GitLab CI basics start when you push code to a GitLab repository. GitLab detects this push and reads the .gitlab-ci.yml file to know what jobs to run. The pipeline starts and jobs run in the order of stages defined. Each job executes its script on a runner and reports success or failure. The pipeline status updates accordingly and finishes when all jobs complete or a failure occurs. This visual trace shows the pipeline moving from pending to running, then success after all jobs finish.

Practice

1. What is the main purpose of the .gitlab-ci.yml file in GitLab CI?

easy

A. To create branches automatically

B. To store the source code of the project

C. To configure user permissions in GitLab

D. To define the stages and jobs for automated tasks like build and test

Solution

1. Step 1: Understand the role of .gitlab-ci.yml

   This file is used to tell GitLab CI what tasks to run automatically, such as building or testing code.

2. Step 2: Identify what the file does not do

   It does not store code, manage permissions, or create branches; those are handled elsewhere.

3. Final Answer:

   To define the stages and jobs for automated tasks like build and test -> Option D

4. Quick Check:

   .gitlab-ci.yml defines jobs and stages [OK]

Hint: Remember: .gitlab-ci.yml controls automation steps [OK]

Common Mistakes:

• Confusing .gitlab-ci.yml with source code files
• Thinking it manages user permissions
• Assuming it creates branches automatically

2. Which of the following is the correct way to define a job named test in .gitlab-ci.yml?

easy

A. job test {
run: echo "Running tests"
}

B. test:
script:
- echo "Running tests"

C. job:
name: test
command: echo "Running tests"

D. task test:
commands:
- echo "Running tests"

Solution

1. Step 1: Recall GitLab CI job syntax

   A job is defined by its name followed by a script section listing commands to run.

2. Step 2: Compare options to correct YAML format

   test: script: - echo "Running tests" uses correct YAML with job name and script list. Others use incorrect keywords or syntax.

3. Final Answer:

   test: script: - echo "Running tests" -> Option B

4. Quick Check:

   Job name + script list = correct job definition [OK]

Hint: Job name + script list is the YAML way to define jobs [OK]

Common Mistakes:

• Using curly braces or incorrect keywords like 'job' or 'task'
• Not using a list for script commands
• Incorrect indentation or missing colons

3. Given this .gitlab-ci.yml snippet:

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building"
test_job:
  stage: test
  script:
    - echo "Testing"

What will be the order of job execution?

medium

A. Both jobs run at the same time

B. test_job runs first, then build_job

C. build_job runs first, then test_job

D. Only build_job runs

Solution

1. Step 1: Understand stages order

   Stages run in the order listed: first 'build', then 'test'.

2. Step 2: Match jobs to stages

   'build_job' is in 'build' stage, so it runs before 'test_job' in 'test' stage.

3. Final Answer:

   build_job runs first, then test_job -> Option C

4. Quick Check:

   Stages run in order listed [OK]

Hint: Jobs run by stage order top to bottom [OK]

Common Mistakes:

• Assuming jobs run in alphabetical order
• Thinking jobs run in parallel by default
• Ignoring the stages list order

4. You wrote this job in .gitlab-ci.yml but it never runs:

deploy_job:
  script:
    - echo "Deploying"
  only:
    - main

What is the likely reason?

medium

A. The job is missing a stage definition

B. The branch name is incorrect; it should be 'master' instead of 'main'

C. The 'only' keyword is deprecated; use 'rules' instead

D. The script command is invalid

Solution

1. Step 1: Check the stage assignment

   The job does not specify a 'stage' key, so it defaults to the 'test' stage.

2. Step 2: Impact of missing stage in global stages

   If the root-level 'stages' does not include 'test', GitLab fails the job because the stage is undefined in the global stages list.

3. Final Answer:

   The job is missing a stage definition -> Option A

4. Quick Check:

   Default stage 'test' must be in 'stages' list [OK]

Hint: Default stage is 'test'; must be defined in 'stages' if used [OK]

Common Mistakes:

• Assuming branch name is wrong without checking
• Forgetting to define a stage (defaults to 'test' if missing)
• Thinking script command syntax is wrong

5. You want a job to run only on the develop branch and after the build stage completes successfully. Which .gitlab-ci.yml snippet correctly achieves this?

hard

A. deploy_job:
stage: deploy
script:
- echo "Deploying"
rules:
- if: '$CI_COMMIT_BRANCH == "develop"'
when: on_success
needs:
- build_job

B. deploy_job:
stage: deploy
script:
- echo "Deploying"
only:
- develop
after_script:
- build_job

C. deploy_job:
stage: deploy
script:
- echo "Deploying"
rules:
- branch: develop
when: always
dependencies:
- build_job

D. deploy_job:
stage: deploy
script:
- echo "Deploying"
except:
- main
needs:
- build

Solution

1. Step 1: Use 'rules' to run job only on 'develop' branch

   The 'rules' keyword with condition '$CI_COMMIT_BRANCH == "develop"' ensures the job runs only on that branch.

2. Step 2: Use 'needs' to wait for 'build_job'

   The 'needs' keyword makes this job wait for 'build_job' to finish successfully before running.

3. Final Answer:

   deploy_job: stage: deploy script: - echo "Deploying" rules: - if: '$CI_COMMIT_BRANCH == "develop"' when: on_success needs: - build_job -> Option A

4. Quick Check:

   'rules' + 'needs' control branch and stage order [OK]

Hint: Use 'rules' for branch and 'needs' for stage dependency [OK]

Common Mistakes:

• Using deprecated 'only' or 'except' keywords
• Confusing 'after_script' with job dependencies
• Incorrect 'needs' or 'dependencies' usage