GitLab CI
Built-in CI/CD with every GitLab repository. Powerful pipelines, self-hosted options, and integrated DevSecOps features.
Overview
GitLab CI is the continuous integration and deployment platform built into GitLab. Introduced in 2015, it uses a .gitlab-ci.yml file in the repository root to define pipelines. GitLab CI is known for its powerful pipeline syntax, built-in container registry, and integrated DevSecOps features (SAST, DAST, dependency scanning, container scanning).
GitLab CI is particularly strong for teams that want an all-in-one platform — source control, CI/CD, security scanning, and monitoring in a single tool. It is also the best choice for teams that need self-hosted CI/CD without the maintenance burden of Jenkins.
What it's used for
GitLab CI is ideal when:
- All-in-one DevOps platform: Source control, CI/CD, security, and monitoring in one tool.
- Self-hosted CI/CD needed: GitLab CE (free) and GitLab EE (paid) can run on-premise.
- Integrated security scanning: Built-in SAST, DAST, dependency scanning, and container scanning.
- Powerful pipeline features: DAG execution, parent-child pipelines, and multi-project pipelines.
Pros & Cons
Pros
- Built into GitLab — no separate CI tool needed
- Powerful pipeline syntax with DAG and parallel execution
- Integrated security scanning (SAST, DAST, SCA)
- Self-hosted option with GitLab CE (free)
- Excellent container registry integration
Cons
- Vendor lock-in to GitLab ecosystem
- Can be resource-intensive for self-hosted instances
- Learning curve for advanced pipeline features
- SaaS pricing can be high for large teams
- Some features only available in paid tiers
Platforms & Integrations
GitLab CI runs on GitLab.com (SaaS) or self-hosted GitLab instances. It supports all major platforms and languages.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Free | Free | 400 minutes/mo CI/CD, basic features |
| Premium | $29/user/mo | 10,000 minutes/mo, advanced CI/CD, security scanning |
| Ultimate | $99/user/mo | 50,000 minutes/mo, full DevSecOps, compliance, support |
NZ Context
GitLab CI is popular among NZ teams that prefer self-hosted infrastructure or want an all-in-one platform. Some NZ government agencies use self-hosted GitLab for data sovereignty. For NZ professionals, GitLab CI experience is valuable but less common than GitHub Actions in the startup ecosystem.
Alternatives
- GitHub Actions — Better for GitHub users with larger marketplace ecosystem.
- Jenkins — More customisable but higher maintenance.
- Azure DevOps — Microsoft's integrated alternative with strong enterprise features.
When to choose GitLab CI
A quick decision guide for NZ teams evaluating CI/CD options.
| Choose GitLab CI when… | Choose something else when… | Combine with… |
|---|---|---|
| Your source code already lives in GitLab and you want pipeline config alongside it with no third-party integrations to maintain | Your team is already on GitHub — GitHub Actions gives you the same co-location benefit without migrating repos | SonarQube for deeper code quality gates beyond GitLab's built-in SAST |
| Data sovereignty or network policy requires self-hosted CI/CD — GitLab CE is free and well-documented for on-prem deployment | You need maximum plugin flexibility and your team has ops capacity — Jenkins on-prem still wins on customisability at scale | Trivy or Grype for container vulnerability scanning layered on top of GitLab's built-in container scanning |
| You want integrated SAST, DAST, dependency scanning, and container scanning without wiring five separate tools together — GitLab Ultimate covers this in a single YAML stanza | Your organisation is deeply invested in Microsoft — Azure DevOps Pipelines integrates more naturally with Entra ID, Azure Boards, and Microsoft licencing agreements | Terraform or Pulumi for infrastructure provisioning triggered by GitLab CI deployment stages |
| You have complex multi-service builds that benefit from DAG (Directed Acyclic Graph) execution — running independent jobs in parallel without a rigid stage ordering | Your team is small, budget-conscious, and already using GitHub Free — 2,000 Actions minutes/month is likely sufficient and avoids a platform split | Playwright or Cypress in a dedicated e2e stage, with test artifacts published back to GitLab's built-in report viewer |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
include: template: Security/SAST.gitlab-ci.yml) rather than bolting on Snyk or Checkmarx. Government contracts often require a documented SAST audit trail — GitLab's security dashboard gives you that for free and keeps findings inside the sovereign boundary. I would also set up protected environments with manual approval gates so no pipeline can deploy to production without a human sign-off logged in the audit trail..gitlab-ci.yml equivalent first, identify which ones require custom runners (Windows, macOS, ARM), and cost out GitLab Premium's shared-runner minutes against the team size. If the math is tight, GitLab's DAG execution model often lets you cut total pipeline time 30–40% by parallelising jobs that were sequentially gated in Jenkins — that's your sell to management.test stage, a Docker image with Playwright pre-installed (mcr.microsoft.com/playwright), and artifacts: reports: junit: so test results surface in the GitLab MR view. Resist the urge to build the perfect pipeline on day one. Get it green, get developers looking at it, then layer on parallelisation (parallel: 4), scheduled nightly runs, and artifact retention. Financial services teams are often conservative about CI changes — ship something small and trustworthy, then expand with their buy-in.The bottom line: GitLab CI's biggest advantage is that the pipeline lives in the same repo as the code — which means version-controlled pipelines, merge request previews of pipeline changes, and no "the Jenkins server is a snowflake" problem. If you are already in GitLab, there is rarely a good reason to use a separate CI tool.
Interview questions
Questions you are likely to get if you list GitLab CI on your CV — with what interviewers are really testing for.
What is the difference between a GitLab CI stage and a job, and why does that distinction matter when you have a long-running test suite?
What they’re really testing: Whether you understand GitLab CI’s execution model at a conceptual level, not just whether you can copy a YAML example.
Strong answer covers: Stages are ordered phases (e.g. build → test → deploy) that run sequentially; jobs within a stage run in parallel by default. Knowing this lets you parallelise a slow Playwright suite across multiple jobs in the same stage rather than waiting for each browser type to finish sequentially, which can cut pipeline time by 50% or more.
When would you use GitLab CI’s DAG (needs:) keyword over relying on the default stage ordering?
What they’re really testing: Whether you have hands-on experience with real pipeline bottlenecks and know advanced YAML features beyond the basics.
Strong answer covers: needs: lets a job start as soon as its direct dependencies finish, bypassing stage gates — so a deploy-to-staging job can begin the moment the Docker build is done without waiting for an unrelated code-quality scan in the same stage. In a microservices repo with many independent services, DAG can halve total pipeline wall-clock time. Trade-off: pipeline graphs become harder to reason about at a glance.
You’re joining a HealthNZ team that self-hosts GitLab on-premise for data sovereignty. The Playwright regression suite passes on your laptop but fails in CI with “browser not found” errors. How do you diagnose and fix this?
What they’re really testing: Whether you can debug environment parity issues in a restricted, air-gapped or on-prem CI context — a common situation in NZ public sector teams.
Strong answer covers: The runner’s Docker image likely lacks browser binaries — switch to mcr.microsoft.com/playwright:v1.x.x-jammy which ships browsers pre-installed. If the self-hosted runner has no internet access, confirm the image is mirrored in the organisation’s internal container registry. Add --headed flag diagnostics locally against the same Docker image to reproduce before pushing. Also check that npx playwright install isn’t being skipped in the CI job script.
Your pipeline was green yesterday but today the sast job fails with new findings. The code didn’t change. What are the likely causes and how do you handle it without just disabling the scan?
What they’re really testing: Whether you treat security findings as signal rather than noise, and whether you know how GitLab’s managed security templates work.
Strong answer covers: GitLab’s Security/SAST.gitlab-ci.yml template updates its analyser images independently of your repo — a new CVE rule may have shipped. Check the pipeline diff for analyser version changes. Triage the finding in GitLab’s vulnerability report (dismiss with justification, or create an issue and accept risk). Never pin the analyser to an old version just to silence alerts — that defeats the purpose of automated scanning.
How would you structure a GitLab CI pipeline to safely support multiple deployment environments (dev, staging, production) for a team at Revenue NZ where production releases require a manual approval gate and a full audit trail?
What they’re really testing: Whether you can design a compliant, enterprise-grade pipeline rather than just a “make it green” pipeline — critical for regulated NZ government environments.
Strong answer covers: Define three GitLab Environments (dev/staging/production) with when: manual and environment: production on the deploy job so GitLab logs who triggered it and when. Use protected environments to restrict who can press the manual trigger button. Enable deployment approvals (GitLab Premium) to require a second person to approve. Pair with protected branches so only merge requests with passing pipelines can land on main — giving Revenue NZ auditors a complete chain-of-custody log in the GitLab UI.