GitLab CI runs test/build/deploy pipelines from `.gitlab-ci.yml`.
On this page
Use this page for fast recall. Use Full documentation when you want the complete end-to-end path.
A simple 5-step flow you can follow when using GitLab CI in real work.
1) Setup
Install/run the tool and confirm version. Create a minimal config.
2) Small change
Do one small action end-to-end to prove the workflow.
3) Validate
Check output, logs, and status. Catch mistakes early.
4) Automate
Convert it into a repeatable script or pipeline step.
5) Productionize
Add safety: secrets, rollback, observability, and docs.
These are practical sequences you can copy into your own checklist or runbook.
Goal: Build, test, and deploy with clear stages and artifacts.
- Define stages: build, test, deploy.
- Cache dependencies and store build artifacts.
- Run deploy only on main branch (or tags).
- Use protected variables for secrets.
- Use environment deployments with manual approvals for prod.
- Stages
- Runners
- Artifacts
Learning path (high-level):
- First pipeline
- Reusable templates
- Optimized jobs
Create CI config
Command
touch .gitlab-ci.ymlCommit config
Command
git add . && git commit -m 'add pipeline'Push and run
Command
git push origin mainShort descriptions and practical intent. Search, filter, copy, and reuse.
Showing 6
gitlab-runner --versionCheck runner version.
gitlab-runner registerRegister a new runner.
gitlab-runner runStart runner service.
gitlab-runner verifyVerify configured runners.
docker logs <runner-container>Inspect runner logs.
curl --header 'PRIVATE-TOKEN: <token>' https://gitlab.com/api/v4/projectsCall GitLab API for automation.
Small blocks you can drop into your terminal, config, or runbook.
Minimal .gitlab-ci.yml (example)
yaml
stages: [build]
build:
stage: build
image: node:20-alpine
script:
- npm ci
- npm run buildWhen things break, follow this order to stay calm and move fast.
- If jobs don’t start: check runner availability and tags.
- If caching is broken: verify cache key and paths in `.gitlab-ci.yml`.
- If secrets are missing: confirm protected variable scopes and branch protections.
The common mistakes that slow people down when using GitLab CI.
- Copy-pasting commands without understanding inputs/outputs and side effects.
- Not documenting defaults (ports, paths, credentials) and then getting stuck in prod.
- Skipping logs and metrics when troubleshooting; always collect evidence first.
Do these tasks in order. You will feel the tool instead of just reading about it.
- Install or run the tool locally (or in Docker) and verify it works with a hello-world action.
- Create a minimal config and run the most common command 3 times (with a small change each time).
- Break something on purpose and document how you debugged it in your Notes.
Use these to test if you truly understand the basics (and can explain them clearly).
- Explain the tool’s role in a real CI/CD pipeline from commit to production.
- Describe the most common failure you’ve seen with this tool and how you fixed it.
- What would you monitor/alert on for this tool in production?