GitLab CI basics - Time & Space Complexity

Time Complexity: GitLab CI basics

O(n)

Understanding Time Complexity

We want to understand how the time GitLab CI takes to run grows as the number of jobs or stages increases.

How does adding more jobs affect the total time GitLab CI spends executing pipelines?

Scenario Under Consideration

Analyze the time complexity of this simple GitLab CI pipeline configuration.

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building..."

test_job_1:
  stage: test
  script:
    - echo "Testing part 1..."

test_job_2:
  stage: test
  script:
    - echo "Testing part 2..."

This pipeline has two stages: build and test. The build stage has one job, and the test stage has two jobs running in parallel.

Identify Repeating Operations

Look for repeated actions that affect total execution time.

• Primary operation: Running each job's script commands.
• How many times: Once per job, so total jobs count.

How Execution Grows With Input

As you add more jobs, the total commands to run increase roughly by the number of jobs.

Input Size (jobs)	Approx. Operations (job scripts run)
10	10
100	100
1000	1000

Pattern observation: The total work grows directly with the number of jobs.

Final Time Complexity

Time Complexity: O(n)

This means the total time to run the pipeline grows linearly with the number of jobs if jobs run sequentially.

Common Mistake

[X] Wrong: "Adding more jobs always makes the pipeline take that many times longer."

[OK] Correct: Jobs in the same stage run in parallel, so adding jobs in one stage may not increase total time as much as expected.

Interview Connect

Understanding how pipeline time grows helps you design efficient CI workflows and explain your choices clearly in discussions.

Self-Check

"What if all jobs were in a single stage running sequentially? How would the time complexity change?"