GitLab CI/CD Associate key terms

The top-level CI/CD structure that runs jobs in defined stages whenever a trigger event occurs, such as a push, merge request, or schedule. It reports an overall status and links all jobs and their logs.

The repository file at the project root that declares pipeline configuration in YAML: stages, jobs, variables, scripts, and rules. GitLab reads it to construct each pipeline, and changes to it trigger pipelines like any other commit.

The smallest unit of work in a pipeline, defined as a top-level YAML key with a script. It runs on a runner, has a stage, and produces a status such as success, failed, or allowed to fail.

A named group of jobs that run in parallel with each other but only after all jobs in prior stages succeed. Order is declared in the top-level stages keyword; jobs in the same stage run concurrently.

The required job keyword listing shell commands the runner executes in order. If any command returns a nonzero exit code, the job fails unless the failure is handled inside the command itself.

A keyword, usable globally or per job, whose commands run before each job's script. Commonly used for installing dependencies or setting up the environment. A failure here fails the job before script runs.

Commands that run after the job's script, even if script failed. Their exit status does not change the job result, so they suit cleanup or log collection but cannot rescue a failed job.

A job keyword that evaluates conditions such as branch name, file changes, or variable values to decide whether a job is added to the pipeline and whether it runs automatically or manually. It replaces only/except.

A top-level keyword with rules that decide whether the entire pipeline is created at all. It also controls pipeline-level attributes such as auto-cancel of redundant pipelines and the name shown in the UI.

A job keyword that makes a job start as soon as its named dependencies finish, ignoring stage order and enabling directed acyclic graph pipelines. Jobs listed in needs must exist in earlier or the same stage.

A pipeline whose job order is driven by needs relationships rather than strict stage sequencing, letting independent job chains run early. It reduces total duration but requires care to avoid circular or missing dependencies.

A keyword that imports configuration from other YAML files, whether local, remote, template, or component sources. Included files are merged with the main file, enabling shared CI logic across projects.

A keyword letting a job inherit configuration from one or more template jobs or hidden keys starting with a dot. It performs a reverse deep merge, so the child job's own values win.

A YAML language feature using an ampersand to mark a block and an asterisk to reuse it. It deduplicates repeated CI configuration but cannot be combined with extends in the same job.

A reusable, versioned unit of pipeline configuration published in a catalog and included with a path and version. It lets teams share maintained CI logic without copying YAML between projects.

A named key-value pair available to pipeline configuration and job scripts, set in YAML, project settings, group settings, or the API. Precedence determines which value wins when the same name is defined in several places.

A variable GitLab supplies automatically to every pipeline, such as CI_COMMIT_BRANCH, CI_PIPELINE_SOURCE, or CI_JOB_TOKEN. They describe the commit, project, and trigger context and cannot be overridden by project settings.

A project or group variable that is only exposed to pipelines running on protected branches or tags. It limits secret exposure to jobs that run trusted refs, such as deployments from the default branch.

A variable whose value GitLab hides in job logs, replacing occurrences with a masked placeholder. Values must meet length and character rules, and masking does not prevent a script from printing transformed versions.

A branch configured with restrictions, such as who may push or merge. Pipelines on protected branches can access protected variables and protected runners, which is central to secure deployment design.

A short-lived token automatically provided to each job, usable for authenticated requests to the GitLab API and for cloning dependent projects when allowed. It expires when the job finishes.

A variable whose value is written to a temporary file, with the variable holding the file path instead of the content. Useful for credentials like kubeconfig or certificates that tools expect as files.

A configuration using the secrets keyword to fetch values from an external vault at job runtime, such as HashiCorp Vault. It avoids storing sensitive values directly in project settings or YAML.

A keyword that saves and restores files between pipeline runs, typically dependency directories, keyed by a string. Cache is best effort and shared storage, so it must never hold secrets or build output needed for correctness.

The identifier that decides which cache archive a job restores and saves. It often includes variables such as lockfile checksums or branch names, and mismatched keys silently produce empty caches.

Files a job produces and uploads for later jobs or download, declared with paths and an optional expiry. Unlike cache, artifacts are guaranteed to pass between stages and are visible in the UI.

A job keyword that uploads structured results such as JUnit test reports, coverage, or security scans so GitLab can display them in merge requests and dashboards. Reports do not need to be downloaded by later jobs.

A job keyword restricting which earlier jobs' artifacts are downloaded into the current job. It narrows downloads for speed but must reference jobs that actually produce artifacts in earlier stages.

The agent process that picks up jobs from GitLab and executes them in a chosen environment. Runners are registered with tags and can be shared, group-level, or project-level.

The runner component that determines how a job actually runs, such as shell, Docker, Kubernetes, or virtual machine. The executor choice controls isolation, available images, and which features work.

A job keyword listing labels a runner must all possess to pick up that job. Tags route work to runners with the right capabilities, and a job whose tags match no runner stays pending.

The container image a job runs in when the runner uses a container executor. It defines the available tools and shell, and can be set globally or per job.

Containers started alongside the job image, such as a database or cache server, reachable by hostname alias. They are commonly used to run integration tests against real dependencies.

A runner configured to accept only jobs from protected branches or tags. Pairing it with protected variables keeps deployment credentials and execution environments off untrusted refs.

A pipeline created for a merge request rather than a branch push, triggered by rules checking CI_PIPELINE_SOURCE equals merge_request_event. It tests the merged result and can run without creating a branch pipeline.

A merge request pipeline that runs without a simultaneous branch pipeline for the same commit. Avoiding duplicates requires workflow rules that prevent branch pipelines when a merge request pipeline exists.

The practice of diagnosing pipeline failures by reading job logs, checking configuration validity with the CI lint tool, and verifying variables, runner tags, and rules. It also covers reproducing failures locally.

A built-in tool that validates CI YAML syntax and simulates pipeline creation, showing which jobs would run and why. It helps catch configuration errors before pushing a commit.