GitLab CI/CD Specialist key terms

A top-level CI/CD definition stored in .gitlab-ci.yml that groups jobs into stages and runs them when triggered by events such as pushes, merges, schedules, or API calls.

The smallest executable unit in a pipeline, defined by a YAML key at the top level and run by a runner; it contains a script and optional configuration such as image, rules, artifacts, and cache.

A named group of jobs that run in parallel with each other but only after all jobs in the preceding stage succeed, unless needs is used to override the ordering.

The required list of shell commands a job executes on the runner; each list item runs as a separate command, and before_script and after_script extend execution around it.

A keyword that lets one job or hidden template inherit configuration from another YAML entry, enabling reuse of shared settings across many jobs without duplication.

Native YAML syntax using & to name a block and * to reuse it, and << to merge mappings; useful for repeating configuration fragments inside a single .gitlab-ci.yml file.

A GitLab-specific YAML tag that copies a value from another part of the configuration, including from files brought in with include, and can be nested inside arrays and maps.

A keyword that imports configuration from other local files, remote URLs, templates, or project files at pipeline creation time, allowing shared CI logic to be maintained centrally.

Reusable, versioned units of pipeline configuration published to the CI/CD Catalog, included with a component path and version and optionally parameterized through inputs.

Typed parameters declared in a component or pipeline header that let callers pass values into included configuration, with optional defaults and validation, replacing older variable-based templating.

A top-level rules list that decides whether the entire pipeline is created or skipped for a given event, controlling which branches, tags, and merge request events can run pipelines.

A per-job ordered list of conditions evaluated top to bottom; the first match sets whether the job runs and can attach attributes such as when, allow_failure, or variables.

The legacy way to include or exclude jobs based on branch names, tags, or refs; it is largely superseded by rules and should not be mixed with rules in the same job.

A job keyword that declares dependencies on other jobs, letting downstream jobs start as soon as those jobs finish rather than waiting for the whole prior stage, forming a directed acyclic graph.

The dependency structure formed when jobs use needs; GitLab renders it as a DAG view and executes jobs in the earliest order allowed by their declared dependencies instead of strict stage order.

A job keyword that sets execution behavior: on_success, on_failure, always, manual, delayed, or never, affecting whether and how the job runs relative to earlier jobs.

A setting that marks a job's failure as non-blocking, so the pipeline can continue and the job shows as a warning rather than causing the pipeline to fail.

A job configured with when: manual that requires a person to click run in the UI or call the API before it executes; it can be optional or blocking depending on allow_failure.

A keyword that starts a downstream pipeline, either as a child pipeline from a YAML file in the same project or as a multi-project pipeline in another project, optionally passing variables.

A pipeline generated by a parent job using trigger with include, often created dynamically by a script; it runs within the same project and is shown nested under the parent pipeline.

A downstream pipeline started in a different project through trigger:project, commonly used to fan out deployments or run integration suites across repositories.

The relationship between a pipeline that starts another and the one it starts; variables and status can flow between them, and downstream pipelines can be configured to block or not block.

An agent process that picks up jobs from GitLab and executes them; runners are registered with a token, tagged, and scoped to a project, group, or instance.

The component of a runner that provisions the environment where a job runs, such as shell, docker, docker-autoscaler, kubernetes, or virtual machine executors.

Labels assigned to runners and referenced in jobs so GitLab only schedules a job on a runner that carries all the job's required tags, controlling where work runs.

A runner setting that allows the runner to accept jobs with no tags; when disabled, only jobs specifying at least one matching tag can be picked up.

A runner executor that runs each job in a fresh container, using the job's image as the environment and optionally a services list for linked containers.

A runner executor that runs job scripts directly on the host machine's shell, sharing installed tools and state between jobs and offering less isolation than containers.

A job or global keyword naming the container image used as the execution environment; it is honored by container-based executors and ignored by the shell executor.

Additional containers started alongside a job, typically databases or caches, reachable by hostname from the job container during execution.

Variables GitLab injects into every job, such as CI_COMMIT_SHA, CI_PROJECT_PATH, CI_JOB_TOKEN, and CI_PIPELINE_SOURCE, providing context about the project and triggering event.

The keyword for defining environment variables available to job scripts; values can be set globally or per job and can reference other variables.

Project or group variables configured so their values are hidden in job logs; values must meet length and character rules, and masking only redacts exact matches.

Variables that are only exposed to pipelines running on protected branches or tags, limiting secret availability to trusted refs and reducing leak risk.

A short-lived token available during a job that authenticates limited API calls, package registry access, and cloning of other projects that permit it.

Integrations such as HashiCorp Vault, Azure Key Vault, or Google Secret Manager that inject secrets into jobs at runtime through ID tokens instead of storing them as CI variables.

A signed OIDC JWT issued to a job that external systems can verify, commonly used to authenticate to cloud providers and secret managers without static credentials.

A keyword that saves and restores files between jobs and pipelines using a key, usually dependency directories; it is best-effort and not guaranteed to be present.

Files a job produces and uploads for later jobs or download; artifacts are passed along needs and stage order and are retained according to expiry settings.

The string that identifies a cache archive; jobs with the same key share cached files, and keys can include variables or a hash of lockfiles for accuracy.

Controls whether a job pulls, pushes, or both for a cache entry: pull, push, or pull-push, useful for avoiding redundant uploads in parallel jobs.

A job keyword restricting which earlier jobs' artifacts are downloaded; unlike needs it does not change execution order, only artifact fetching.

A keyword that splits one job into multiple concurrent instances, either a fixed count or a matrix of variable combinations, each running with a distinct CI_NODE_INDEX.

A parallel form that generates one job per combination of listed variable values, enabling test grids across versions, platforms, or configurations.

A keyword that serializes jobs sharing the same group name, ensuring only one runs at a time, commonly used to prevent concurrent deployments to the same environment.

A keyword that records a deployment target with a name and optional URL, enabling tracking, stop actions, and protection rules for that environment.

A branch configured with push and merge restrictions; pipelines on it can access protected variables and protected runners, and deployments may require approval.

An environment with deployment restrictions, such as allowed branches or required approvals, so only authorized pipelines can deploy to sensitive targets like production.

A predefined variable naming the event that created the pipeline, such as push, merge_request_event, schedule, web, or pipeline, and frequently used in rules conditions.

A pipeline run for a merge request event rather than a branch push, often used with rules to run validation on proposed changes before merging.

A merge request pipeline that is not tied to a branch pipeline; it occurs when no branch pipeline exists for the source branch, affecting which jobs and variables apply.

The practice of reducing pipeline duration and runner load through caching, artifact scoping, needs-based ordering, parallelization, and avoiding unnecessary jobs.

Diagnosing failed or stuck pipelines by reading job logs, CI Lint results, exit codes, runner logs, and error messages, then adjusting configuration or runner capacity.

A built-in validator that checks .gitlab-ci.yml syntax and logic, can simulate pipeline creation with variables, and reports errors before a real run.

The captured output of a job's script, including section markers and errors; logs are the primary source for diagnosing failures and verifying variable values.

A job keyword specifying how many times GitLab should automatically rerun a job on failure, optionally limited to certain failure reasons such as runner_system_failure.