Does this cover every GitLab CI feature?

No. It covers the core building blocks nearly every pipeline needs: stages, jobs (image, script, stage), cache paths, artifact paths, and branch/merge-request rules. GitLab CI supports many more keywords (includes, DAG needs, parallel matrices, services, environments); for those, use this tool's output as a starting point and extend it by hand.

How do the 'only on main' and 'only on merge requests' toggles work?

They add a `rules:` block to every job using GitLab's predefined CI/CD variables, `$CI_COMMIT_BRANCH == "main"` and `$CI_PIPELINE_SOURCE == "merge_request_event"`. Enable both if you want a job to run in either case; enable neither to leave the job unrestricted (it runs on every trigger).

Why does my job fail validation with a stage error?

Every job's `stage` field must exactly match one of the stage names you listed in the stages field above it. This mirrors GitLab's own validation: a job referencing an undefined stage fails the pipeline before it even starts.

What goes in the cache and artifacts paths fields?

Cache paths are directories GitLab should persist between pipeline runs to speed up jobs, most commonly `node_modules/` or a package manager's download cache. Artifact paths are files or directories to upload after the job finishes, like a `dist/` build output or test reports, so later stages or a human can download them.

GitLab CI Generator - Build a .gitlab-ci.yml

Overview

Introduction

A .gitlab-ci.yml file is usually built up over months by copy-pasting from other projects and GitLab's own docs, and it's easy to end up with a job that's missing a stage reference or has script lines under the wrong key.

This tool generates a complete, valid .gitlab-ci.yml from a structured form: stages, jobs, caching, artifacts, and branch/MR rules, so you start from working YAML instead of a blank file.

What Is GitLab CI Generator?

A form-driven generator for GitLab CI/CD pipeline configuration. You define an ordered list of stages, then one or more jobs that each belong to a stage, run in a Docker image, and execute a list of script commands.

Optional cache paths, artifact paths, and a rules toggle (limit to the main branch and/or merge request pipelines) get applied to every job in the generated file.

How GitLab CI Generator Works

Each field maps directly onto a GitLab CI/CD YAML keyword: `stages` becomes the top-level stages list, each job's name becomes its own top-level key with `stage`, `image`, and `script`, and the cache/artifacts/rules toggles add the matching `cache:`, `artifacts:`, and `rules:` blocks under every job.

Validation happens before generation: every job must reference a stage that's actually in your stages list, and every job needs at least one script line, since an empty script is invalid GitLab CI YAML.

When To Use GitLab CI Generator

Use it when scaffolding a new GitLab project's CI pipeline and you want a correct starting structure instead of hand-typing YAML indentation.

It's also useful for quickly sketching a multi-stage pipeline (build, test, deploy) to review with a team before wiring up the real scripts.

Often used alongside GitHub Actions Workflow Generator, Jenkins Pipeline Generator and .gitignore Generator.

Features

Advantages

Produces syntactically valid, correctly indented YAML every time, eliminating the most common source of pipeline breakage: indentation mistakes.
Validates that every job's stage actually exists in the stages list before generating output.
Applies cache, artifacts, and rules consistently across every job instead of requiring you to repeat the same blocks by hand.

Limitations

Doesn't support advanced GitLab CI features like `needs:` DAGs, `include:` for shared pipeline templates, `services:`, or `environment:` deployment tracking.
Rules are limited to two common conditions (main branch, merge requests); complex rule chains with `changes:` or `exists:` need manual editing afterward.

Examples

A two-stage Node.js pipeline

Input

stages: build, test; job 'build' (stage: build, image: node:20, script: npm install / npm run build); cache path: node_modules/

Output

stages:
  - build
  - test

build:
  stage: build
  image: node:20
  script:
    - npm install
    - npm run build
  cache:
    paths:
      - node_modules/

The stages list becomes the top-level `stages:` array, and the job's fields map directly onto `stage`, `image`, `script`, and `cache.paths`.

Best Practices & Notes

Best Practices

Keep stage names short and lowercase (build, test, deploy) to match GitLab's own conventions and keep pipeline graphs readable.
Cache dependency directories (node_modules/, .m2/, vendor/) rather than build output, artifacts are the right mechanism for passing build output between stages.
Enable the merge-request rule on test/lint jobs so they run on every MR, but reserve the main-branch rule for deploy jobs you don't want firing on every push.

Developer Notes

The generator builds the YAML as plain indented text rather than through a YAML serialization library, since GitLab CI YAML has enough structural conventions (list items under `paths:`, script arrays) that hand-controlled indentation is more predictable than a generic serializer's formatting choices. Job names are validated against GitLab's own allowed character set for job keys before being emitted as top-level YAML keys.

GitLab CI Generator Use Cases

Scaffolding a new GitLab repository's first .gitlab-ci.yml
Sketching a multi-job pipeline structure to review before filling in real build scripts
Quickly producing a working pipeline for a coding exercise or demo repo

Common Mistakes

Referencing a stage in a job that doesn't appear in the stages list, GitLab will reject the pipeline outright with a config error.
Forgetting that cache paths are for speeding up future jobs (dependencies), not for publishing build output, use artifacts paths for that instead.

Tips

Generate a minimal pipeline first, commit it, and confirm it runs green in GitLab before layering on caching, artifacts, and rules.

GitLab CI Generator