What is GitLab CI and how does the .gitlab-ci.yml file work?
Learn what GitLab CI is and how the .gitlab-ci.yml file defines stages, jobs, and Runners to automate your build, test, and deploy pipeline.
Expected Interview Answer
GitLab CI is GitLab's built-in continuous integration and delivery system that automatically runs pipelines defined in a `.gitlab-ci.yml` file at the root of your repository whenever code is pushed.
The `.gitlab-ci.yml` file declares stages (like build, test, deploy) and jobs, each job specifying a script to run, an executor image, and rules for when it should trigger. GitLab Runners pick up these jobs, execute them in isolated environments, and report status back. Jobs in the same stage run in parallel, and the pipeline advances to the next stage only when the current one succeeds, giving you an automated gate from commit to production.
- Pipeline-as-code lives with the repository and is version controlled
- Automatic pipeline triggering on every push or merge request
- Parallel job execution within a stage speeds up feedback
- Runners isolate builds in clean, reproducible environments
- Fine-grained control via rules, stages, and dependencies
AI Mentor Explanation
Think of a team's fixed match-day routine written on a board: warm-up, then batting nets, then fielding drills, and only if each passes does the team take the field. The `.gitlab-ci.yml` is that board — it lists the ordered stages, and the support staff (Runners) carry out each drill exactly as written every time the squad reports for practice after a code change.
Step-by-Step Explanation
Step 1
Add the config file
Create `.gitlab-ci.yml` at the repository root; GitLab detects it automatically on the next push.
Step 2
Define stages
Declare an ordered `stages:` list such as build, test, deploy — jobs run stage by stage.
Step 3
Write jobs
Each job names its stage, an `image:`, and a `script:` of shell commands to execute.
Step 4
Control execution
Use `rules:` or `only/except` to decide when a job runs, and `needs:` for dependencies across stages.
Step 5
Register a Runner
A GitLab Runner (shared or self-hosted) picks up queued jobs and executes them in isolated environments.
Step 6
Review pipeline results
GitLab shows pass/fail per job and stage; failures block later stages and the merge request.
What Interviewer Expects
- Knows the pipeline is defined as code in .gitlab-ci.yml
- Understands stages run sequentially and jobs within a stage in parallel
- Can explain the role of GitLab Runners as executors
- Familiar with rules, only/except, and needs for job control
- Understands failure in a stage blocks downstream stages
Common Mistakes
- Confusing stages (order) with jobs (units of work)
- Thinking Runners are part of GitLab rather than separate executors
- Assuming jobs in the same stage run sequentially
- Forgetting that a failed job blocks the whole pipeline unless allow_failure is set
- Placing the config file anywhere other than the repository root
Best Answer (HR Friendly)
“GitLab CI is a tool that automatically builds, tests, and deploys your code whenever developers push changes. The steps are written in a simple file called .gitlab-ci.yml that lives in the project, so the whole process runs the same way every time without anyone doing it by hand.”
Code Example
stages:
- build
- test
- deploy
build-job:
stage: build
image: node:20
script:
- npm ci
- npm run build
test-job:
stage: test
image: node:20
script:
- npm test
deploy-job:
stage: deploy
image: alpine:3.20
script:
- ./deploy.sh
rules:
- if: '$CI_COMMIT_BRANCH == "main"'Follow-up Questions
- What is the difference between a stage and a job in GitLab CI?
- How do shared Runners differ from specific self-hosted Runners?
- What does the needs keyword do and how does it enable a DAG pipeline?
- How do you run a job only on the default branch or on merge requests?
- How does GitLab CI compare to GitHub Actions or Jenkins?
MCQ Practice
1. Where must the GitLab CI configuration file be located by default?
GitLab automatically detects a file named .gitlab-ci.yml at the root of the repository.
2. How do jobs within the same stage execute?
Jobs in the same stage run in parallel; the pipeline moves to the next stage only when all succeed.
3. What component actually executes GitLab CI jobs?
GitLab Runners are separate agents that pick up queued jobs and run them in isolated environments.
Flash Cards
What triggers a GitLab CI pipeline? — A push, merge request, tag, or schedule detected by GitLab, which reads .gitlab-ci.yml.
What is a stage? — An ordered group of jobs; stages run sequentially and jobs within a stage run in parallel.
What is a GitLab Runner? — A separate agent, shared or self-hosted, that executes pipeline jobs in isolated environments.
What does 'rules:' do? — Defines conditions that decide whether and when a job is added to the pipeline.
Continue Learning
Related Interview Questions
What is Jenkins and how does it fit into a CI/CD workflow?
easy
What is the difference between a Jenkins freestyle project and a pipeline?
medium
What is the difference between a build artifact and a cache in CI/CD?
medium
What is the difference between a self-hosted and a cloud-hosted CI/CD system?
medium