GitLab
CI/CD & Code
Freemium
<What you get/>
Test stages defined in your pipeline file, versioned with the code
A fast merge-request tier that gives developers a signal before review
Reports and traces stored as artefacts attached to the run that produced them
A realistic split between per-merge and scheduled runs, tuned to your runner capacity
What it is
GitLab combines source control, CI/CD, and issue tracking in one platform, so pipelines live next to the code they build. For QA the practical benefit is immediacy: a merge request can be blocked on its own test run, and results appear in the review rather than in a separate tool someone has to remember to check.
How PerfectQA uses GitLab
On GitLab projects we put test execution directly in the pipeline definition beside the build, so coverage is part of how code ships rather than a separate process. Merge request pipelines run the fast tier — unit, API, a smoke subset — so a developer gets a signal before review, and the full regression runs on the main branch or on a schedule where run time makes that sensible. We use pipeline stages to fail early and cheaply, artefacts to keep reports and traces attached to the run that produced them, and the merge request integration so results appear where the review conversation is happening rather than in a dashboard nobody opens. Where clients run self-managed GitLab with limited runners, we tune the split between what runs per-merge and what runs nightly, because an over-ambitious pipeline that developers learn to bypass is worse than a modest one they trust.
Category
CI/CD & Code
In our stack
5 years
Projects
19 delivered
Frequent questions
Should every test run on every merge request?
Can we see test results in the merge request?
We're on self-managed GitLab with few runners. Is that a problem?
Can GitLab replace our Jenkins?
Every stack is different
Tell us yours, and we’ll show you where this fits
