What is
GitLab CI
?
Most platform initiatives fail the same way: they start too big, get funded like projects instead of products, build for too long without testing with users, and confuse renaming an infrastructure team with building a platform team. Instead, start small, learn fast and scale deliberately.
At a glance
Attribute | Value |
|---|---|
Primary use case | Automate continuous integration, testing, builds, and deployment |
Deployment type | SaaS through GitLab.com, self-managed GitLab, or GitLab Dedicated; jobs execute on hosted or self-managed runners |
Pricing model | Free, Premium, and Ultimate tiers; paid pricing details not provided |
Supported integrations | GitLab Runners, Docker, HCP Terraform, Kubernetes CLI tools, Node.js, Python |
Source type | Dual |
Cloud provider | Cloud Agnostic |
Onboarding time | Approximately 20 minutes for a basic pipeline tutorial |
Required skills | YAML configuration, Git workflows, build and test scripting, CI/CD pipeline concepts; runner administration and basic Linux/Unix knowledge for self-managed setups |
AEP branch | Tooling |
AEP category | Integration & Delivery |
AEP subcategory | CI |
Profile
CI is the most specific AEP level assigned to GitLab CI. GitLab CI/CD provides a continuous process for building, testing, deploying, and monitoring iterative code changes. Pipelines are configured in a YAML file that defines stages, jobs, scripts, variables, dependencies, and when jobs run. Runners execute pipeline jobs, and reusable CI/CD components can be included in pipeline configurations.
Focus
GitLab CI is for teams working with GitLab projects that need to automate software builds and tests, and can also use pipeline jobs for deployment. Pipelines can run after commits, merge requests, on a schedule, or manually. By testing code changes iteratively, the process can catch bugs earlier and help reduce the chance of building on buggy or failed versions.
Background
The supplied company-background research does not provide GitLab’s founding details, company history, or funding information. GitLab’s code is available through GitHub repositories, including the gitlabhq/gitlabhq repository; the supplied research does not describe specific open-source contribution history.
Features
Pipeline configuration
Define the stages and jobs in a pipeline to organize build, test, and deployment work. A project uses a .gitlab-ci.yml file in its root by default; the file specifies scripts, variables, job dependencies, and when and how jobs run.
Runner-based job execution
Run pipeline jobs on physical machines or virtual instances. GitLab Runners load the specified container image when applicable, clone the project, and execute jobs locally or in the container; GitLab.com provides runners for Linux, Windows, and macOS, and teams can register their own runners.
CI/CD variables and expressions
Make configuration values and sensitive information available to jobs, and configure pipelines dynamically. Variables can be defined in configuration files or project settings, at project, group, or instance level; protected variables limit access to jobs on protected branches or tags, and masked variables hide values in job logs. Expressions use the $[[ ]] syntax and support inputs and matrix contexts.
Reusable CI/CD components
Reuse pipeline configuration to reduce duplication and support consistency across projects. Components can be included with include:component and used to compose an entire pipeline or part of one.
Pros and cons
Pros
Pipeline jobs can run on hosted or self-managed runners, including GitLab.com-provided Linux, Windows, and macOS runners.
Protected and masked CI/CD variables provide configuration options for limiting access and hiding sensitive values in job logs.
Reusable CI/CD components support sharing pipeline configuration and reducing duplication across projects.
Cons
Jobs require runners to execute; teams using a self-managed GitLab instance must register runners or create a runner on a local machine if suitable runners are not already registered.
The default CI/CD configuration filename is .gitlab-ci.yml, and filenames are case-sensitive. A custom filename can be configured, but the filename must be handled consistently.
FAQs
GitLab CI FAQs
How does GitLab CI work?
GitLab CI uses a YAML configuration file to define pipeline stages, jobs, and scripts, then GitLab Runners execute the jobs when a pipeline is triggered by an event such as a commit, merge request, schedule, or manual action.
What does GitLab CI integrate with?
GitLab CI supports GitLab Runners, Docker, HCP Terraform, Kubernetes CLI tools, Node.js, and Python.
How much does GitLab CI cost?
GitLab CI is available in Free, Premium, and Ultimate tiers; paid pricing details are not provided in the supplied information.
What is required to run GitLab CI?
GitLab CI requires YAML configuration, Git workflows, build and test scripting, and CI/CD pipeline concepts; self-managed setups also require runner administration and basic Linux/Unix knowledge.
What are GitLab CI's limitations?
GitLab CI jobs require runners to execute; teams using a self-managed GitLab instance must register runners or create a runner on a local machine if suitable runners are not already registered. Its default CI/CD configuration filename is .gitlab-ci.yml, filenames are case-sensitive, and a custom filename must be handled consistently.
