GitLab CI/CD review: what it is, tutorial, pros and cons

A pipeline is a set of jobs declared in .gitlab-ci.yml at the root of the repository. Jobs belong to stages that run in order, and jobs in the same stage run in parallel. The needs keyword lets a job start as soon as the jobs it depends on finish, ignoring stage order, which shortens pipelines where a fast API suite should not wait for a slow build of something unrelated. rules decide whether a job is added to a pipeline at all, based on branch, changed files or variables. include and CI/CD components pull shared configuration from other files and projects, so a QA team can publish one test job template that many projects reuse.

Jobs are executed by GitLab Runner, an MIT-licensed agent that polls GitLab for work. Each runner uses an executor, most often Docker or Kubernetes, which starts the image named in the job and runs its script inside it. Runners are scoped to the instance, a group or a project. On GitLab.com, instance runners hosted by GitLab are available on Linux, with Windows and macOS in beta, and a job with no image falls back to ruby:3.1. Your own runners are registered with a runner authentication token prefixed glrt-; the older registration tokens have been disabled by default since GitLab 17.0 and are scheduled for removal in 20.0.

A job keeps files through artifacts:paths, uploaded when the job ends and downloadable from the job page. artifacts:reports is a separate channel that GitLab parses: reports:junit takes JUnit XML files and turns them into the Tests tab of the pipeline and the test summary in the merge request. By default artifacts upload only for successful jobs, so test jobs need artifacts:when: always. On GitLab.com, artifacts expire after 30 days unless expire_in says otherwise, although artifacts from the latest successful pipeline on each ref are kept by default. Reports must be files of up to 30 MB each and 100 MB per job in total.

parallel: N creates N copies of a job, named test 1/N to test N/N, each with CI_NODE_INDEX and CI_NODE_TOTAL set, and N can be from 1 to 200. A runner that understands sharding, such as Playwright with --shard, uses those variables directly; for others, a short script picks every Nth spec file. parallel:matrix instead creates one job per combination of variable values, such as browser and environment, up to 200 permutations. In both cases jobs beyond the available runner capacity wait as pending, so parallelism is bounded by runners, not by the YAML.

Order jobs by cost and use needs so fast feedback is not held up: unit tests and linting first, then API tests that need only the build, then UI suites that need a deployed review environment. Use rules to run the full regression on the default branch and on a schedule, and a smaller smoke set on merge requests, with rules:changes to skip suites unaffected by a change where that is safe. Put the common test job in a template or CI/CD component, with the image, cache, retry policy and report paths, and extend it per suite. Keep credentials in masked and protected CI/CD variables, scoped to environments, never in the YAML.

parallel creates numbered copies of a job, and Playwright’s shard option reads the index and total directly. Each copy uploads its own JUnit file under a unique name, and GitLab merges every copy’s results into one Tests tab. Use the official Playwright image whose version matches the package, so browsers and library agree. Keep traces and screenshots in artifacts:paths with a short expiry, since only failing runs need them, and size N to the runners you actually have: copies beyond capacity simply queue.

A bare retry: 2 retries every failure type, which means a genuinely failing test can pass on the second or third attempt and the merge request goes green. Restrict retries to failures that are not about the code: runner_system_failure, api_failure and, since GitLab 19.1, runner_configuration_error for problems such as an image that cannot be pulled. Handle test-level flakiness inside the test runner, which can record that a test needed a retry, and watch the 14-day failure count in the test report to find the worst offenders.

Hosted Linux runners suit most API and browser suites that test a publicly reachable environment, and larger machine sizes trade a higher cost factor for shorter jobs. Register your own runners when tests must reach systems inside a private network, need physical devices, or would exhaust the compute quota; on a Kubernetes executor each job gets a fresh pod, which keeps runs isolated. Tag runners by capability, such as android or gpu, and select them with tags in the job. Self-managed GitLab instances can disable instance runners entirely and run everything on their own infrastructure.

Pipelines grow by copying jobs, so set conventions early: one template per kind of test job, every job with an explicit image and timeout, interruptible on anything that can safely be cancelled, and expire_in on artefacts so storage does not grow without limit. Name JUnit files uniquely per parallel copy so nothing is overwritten. Review compute usage on the usage quotas page monthly, since a nightly suite moved from small to large runners triples its minutes. Use the pipeline editor’s validation before pushing YAML changes, which catches most syntax mistakes without a wasted run.