The Fundamentals make you able to write and debug a complete GitLab CI/CD pipeline. In 16 lessons, you go from "I don't know what a stage is" to "I can structure a clean pipeline, manage variables, control execution with rules, publish images and packages, enable the security scanners, and above all debug when something doesn't work".
These Fundamentals group levels C1 ("write a pipeline and read its failures") and C2 ("deliver") of the course: 5 modules, that is 16 lessons, of which 12 carry a lab attached to the page. Level C3 ("industrialise") and level C4 ("secure and tool") build on this foundation.
No abstract theory: every concept is tied to a real use case. You learn to ask the right questions, use the right YAML keywords, and solve problems before they reach production.
Who is this for?
The Fundamentals are aimed at three profiles:
The motivated beginner. You have never written a .gitlab-ci.yml. You know GitLab can "run tests automatically", but you don't know where to start. You want to understand the logic before copy-pasting examples.
The developer who endures the CI. You sometimes edit your project's pipeline, but as soon as a job stays "pending" or "skipped", you are stuck. You know the problem is "somewhere in the YAML", but you don't know where to look.
The ops engineer who wants to structure what they know. You learned GitLab CI/CD on the job, fixing broken pipelines. You want to fill the gaps, understand the underlying mechanisms, and have a systematic debugging method.
What are the operational objectives?
These ten objectives are written as actions, not as knowledge. This is deliberate: on a pipeline, knowing what a stage is is useless as long as you cannot say why the job did not start. The last two points (debugging "pending" and "skipped") are the ones that save you the most time day to day, and they are also the ones that require having understood all the previous ones.
By the end of the Fundamentals, you will be able to:
- Structure a
.gitlab-ci.yml: stages, jobs, scripts, with best practices. - Understand runners: know why a job runs on a given machine, with given tags.
- Manage artifacts and cache: store results, speed up builds, avoid the pitfalls.
- Use variables: scopes, precedence, CI_* variables, protected secrets.
- Control execution with
rules: if, changes, exists, when conditions. - Configure triggers: push, MR, tags, schedules, manual.
- Use environments: dev, staging, prod, stop actions.
- Generate reports: junit, coverage, artifacts reports.
- Debug "pending": identify a missing runner, tags mismatch, quotas.
- Debug "skipped": understand workflow:rules vs rules, legacy only/except.
Why this teaching format?
Starting from what you already know
You have already seen a GitLab pipeline in the web interface. You have seen green, red or grey jobs. This course anchors the concepts on those experiences: we start from what you see (the stuck job) and work back to the cause (the badly tagged runner).
What is the logical progression?
The Fundamentals hold five modules, three at level C1 and two at level C2. Durations are not repeated here: they appear lesson by lesson in the course outline, on the left, and they include the lab when a lesson carries one.
| Level | Module | Content |
|---|---|---|
| C1 | First pipeline, and reading its failures | Concepts, first pipeline, validation, reading the logs |
| C1 | Runners, artifacts and cache | Where a job runs, what it keeps and what it reuses |
| C1 | Variables, secrets and run conditions | Variables, rules, triggers |
| C2 | Environments, reports and diagnosis | Environments, test reports, a pending job, a pipeline that never starts |
| C2 | Wrap-up, registries and built-in scanners | Complete pipeline, registries, security scanners |
Each lesson builds on the previous lessons. You will not see rules (lesson 8) before understanding variables (lesson 7), because a condition is almost always written by testing a CI_* variable.
Why is every concept tied to a failure case?
We do not learn runners "because they are on the syllabus". We learn them because a "pending" job almost always comes from a missing runner or from tags: that match no available runner. We do not learn workflow:rules for general knowledge, but because it is one of the causes of pipelines that do not start at all.
What do the 16 lessons cover?
Basics and structure (lessons 1 to 6)
This first block builds the vocabulary and the checking reflexes. Note the order: you write a pipeline (lesson 2), you learn to validate it before pushing (lesson 3), then to read a failure (lesson 4). Many beginners skip lessons 3 and 4 to go faster; yet they are the ones that spare you the back-and-forth of "fix ci" commits on the branch.
| Lesson | Content | Key skill | Practice |
|---|---|---|---|
| 1. Getting started with GitLab CI/CD | Pipeline, stage, job concepts | Understand the vocabulary | quiz |
2. Writing a .gitlab-ci.yml file | YAML structure, stages, jobs, script | Write a minimal pipeline | lab |
| 3. Validating your pipeline | Pipeline Editor, CI Lint, API, IDE | Catch YAML errors before the push | lab |
| 4. Debug: reading the logs | Logs, sections, errors | Understand why a job fails | lab |
| 5. Runners | Executors, tags, shared/specific | Know where a job runs | lab |
| 6. Artifacts and cache | Storage, retention, performance | Optimize builds | lab |
Execution control (lessons 7 to 10)
This block answers a single question: when should a job run, and with which values? Variables (lesson 7) come before rules (lesson 8) because a rules:if condition is almost always written by testing a CI_* variable. Without this base, the rules syntax stays a formula you copy without understanding.
| Lesson | Content | Key skill | Practice |
|---|---|---|---|
| 7. Variables and secrets | Scopes, CI_*, protected, file | Parameterize jobs | lab |
8. Conditions (rules) | if, changes, exists, when | Control when a job runs | lab |
| 9. Triggers | Push, MR, tags, schedules, manual | Understand pipeline sources | lab |
| 10. Environments | dev/staging/prod, stop actions | Manage deployments | quiz |
Quality and reports (lesson 11)
A single lesson, but a profitable one: it is the one that surfaces test results in the merge request interface, instead of leaving them buried in the job logs. It is the difference between a CI the team looks at and a CI nobody reads.
| Lesson | Content | Key skill | Practice |
|---|---|---|---|
| 11. Quality reports | junit, coverage, artifacts reports | Use test results | lab |
Troubleshooting (lessons 12 and 13)
| Lesson | Content | Key skill | Practice |
|---|---|---|---|
| 12. Troubleshooting "pending" | Missing runner, tags, quotas | Unblock a job | lab, which carries both failures |
| 13. Troubleshooting "skipped" | workflow:rules, rules, only/except | Understand why it does not start | quiz |
Summary (lesson 14)
This lesson brings no new notion: it makes you assemble all the previous building blocks into a single complete .gitlab-ci.yml, with a production readiness checklist. It is the best revealer of half-understood notions, and the resulting pipeline will serve you as a starting template on your own projects.
| Lesson | Content | Key skill | Practice |
|---|---|---|---|
| 14. Summary: a complete pipeline | Mini-capstone, prod checklist | Assemble everything you learned | quiz |
Registries and security (lessons 15 and 16)
These two lessons step outside the pipeline to look at what it produces and what it lets through. Lesson 15 covers building and publishing images without privileged mode; lesson 16 plugs in the GitLab scanners (SAST, Secret Detection, Dependency and Container Scanning) so that vulnerabilities surface in the merge request rather than in production.
| Lesson | Content | Key skill | Practice |
|---|---|---|---|
| 15. GitLab registries | Container Registry, Package Registry, Dependency Proxy, Buildah | Build and publish images and packages | lab |
| 16. Security scanners | SAST, DAST, Secret Detection, Dependency/Container Scanning | Detect vulnerabilities in the MR | lab |
What working method is recommended?
Pace: 2 to 3 lessons per week. A lesson takes 16 to 35 minutes of reading, a lab 30 to 45 minutes of practice.
Systematic practice: follow each lesson with the lab it carries, instead of moving on to the next one. A concept you did not practice is a concept you forget.
Note-taking: keep a personal "cheatsheet" with the YAML keywords and the patterns you discover. It will serve you when troubleshooting.
In which order should you read the lessons?
The lessons follow the teaching order of the Fundamentals. If you start from zero, read them in that order. If you come looking for a precise answer, the three debugging lessons (Debug: reading the logs, Debug pending, Debug skipped) are meant to be consulted when facing a failure.
The basics start with Core concepts
(pipeline, stage, job: the CI/CD vocabulary), then the
First pipeline writes a working .gitlab-ci.yml
from A to Z. Validating your pipeline catches
errors before the push with the Pipeline Editor, CI Lint and the API, and
Debug: reading the logs explains why a job fails. The
Runners show where and how your jobs run, and
Artifacts and cache store results to
speed up builds.
Execution control follows with Variables and secrets
(scopes, CI_*, protected, file), Execution conditions (rules)
(if, changes, exists, when), Triggers (push, MR,
tags, schedules, API) and Environments (dev, staging,
prod). Quality reports then makes use of JUnit,
coverage and Code Climate.
Troubleshooting comes next: Debug pending answers "why does my job stay waiting?" and Debug skipped answers "why is my pipeline skipped?". The Summary: a complete pipeline assembles all the building blocks of these two levels into a mini-capstone. Finally, two lessons step outside the pipeline to look at what it produces: GitLab registries (Container Registry, Package Registry, Dependency Proxy) to build and publish, and Security scanners (SAST, DAST, secrets, dependencies) to detect vulnerabilities in your MRs.
How is the practice organised?
Practice is not a separate exercise series sitting next to the course: every lesson that teaches a hands-on move carries its lab at the bottom of the page, in a "Hands-on lab" section. Nothing to look for elsewhere, and you practise the moment the notion has been read.
The lab runs on a GitLab CE forge of your own, on a virtual machine with its runner and its registry: no minute quota, no identity check, and a project you can break as often as needed. The mark is not about the commands you typed but about the resulting state, read from the forge API: the jobs that actually ran, the artifacts produced, the environments recorded.
Four lessons in this module have no lab and are assessed by their quiz: the core concepts, which set the vocabulary, the environments, the summary, which assembles what the others made you practise, and Debug skipped, whose failure is played by the Debug pending lab.
What will you have at the end of the Fundamentals?
You will have a reference pipeline that you can adapt to your projects. This pipeline will include:
- A clear structure (logical stages, well-named jobs)
- Well-scoped variables (project, group, pipeline)
- Rules that precisely control execution
- Artifacts and cache configured for performance
- Environment management (dev → staging → prod)
- Integrated test reports
Above all, you will have a debugging method: facing a "pending", "skipped" or "failed" job, you will know exactly where to look.