GitLab CI Generator

Generate a .gitlab-ci.yml pipeline without memorising GitLab's YAML keywords. Choose a language, tick the stages you want — build, test, lint, deploy — and the tool writes jobs with the right base image, install commands, dependency caching, and artifacts passed between stages. Copy it to the root of your repo and the pipeline runs on your next push. Everything is generated in your browser.

Stages:
.gitlab-ci.yml

How to use the GitLab CI Generator

Pick your language to load a sensible base image and the install, lint, test, and build commands for that ecosystem. Tick the stages you want — most projects run build, lint, and test on every change and add deploy once a release target exists. Leave caching on so dependencies are restored between pipelines instead of downloaded every time, which is usually the single biggest speed-up. The file regenerates live; save it as .gitlab-ci.yml in the repository root.

The generated jobs use conventional commands (for example npm ci, pytest, go test ./...), so adjust them to match your actual scripts and test runner. The deploy job is intentionally a stub guarded to run only on the default branch — replace its script with your real deployment, whether that is pushing an image, calling a deploy API, or using GitLab environments. Pipelines run automatically on push once the file is committed; check the results under Build → Pipelines in GitLab.

How GitLab CI pipelines work

GitLab CI/CD is configured by a single file, .gitlab-ci.yml, at the root of your repository. When you push, GitLab reads it and builds a pipeline — a set of jobs organised into stages that run in sequence. Jobs in the same stage run in parallel; the next stage starts only once the previous one succeeds. A typical ordering is build, then lint and test, then deploy, so a failing test never reaches production.

Each job declares an image (a Docker image the job runs inside), a stage, and a script of shell commands. GitLab Runners pick up jobs and execute them in clean containers, which is what makes builds reproducible. Two keywords do most of the heavy lifting for speed and data flow: cache persists directories like node_modules or .cargo across pipelines so dependencies are not re-downloaded every run, and artifacts pass files produced by one job — compiled output, a coverage report — to later stages and make them downloadable from the UI.

Control over when jobs run comes from rules (and the older only/except). You can run the full pipeline on merge requests and the default branch, skip expensive jobs on documentation-only changes, or gate deployment behind a manual approval. Combined with environments, which track what is deployed where, this lets a single file describe everything from a quick lint check to a multi-stage production rollout. This generator produces a clean starting pipeline with the common stages and caching wired up, which you then tailor to your project's scripts and deployment target.

Common use cases

  • New repositories. Add a working CI pipeline in one step instead of writing YAML from scratch.
  • Standardising builds. Give every project the same build, lint, and test stages with caching.
  • Learning GitLab CI. See how stages, jobs, cache, and artifacts fit together for your language.
  • Faster pipelines. Add dependency caching to a project that currently reinstalls every run.

Frequently asked questions

Where does the .gitlab-ci.yml file go?
At the root of your repository. GitLab automatically detects it and runs a pipeline on each push (subject to the rules in the file). You can change the path in project settings, but the root is the convention and what this generator assumes.

What is the difference between cache and artifacts?
Cache speeds up jobs by reusing dependency directories across pipelines — it is best-effort and may be missing. Artifacts pass specific files produced by a job to later stages in the same pipeline and make them downloadable; they are reliable and versioned. Use cache for dependencies and artifacts for build output and reports.

Why do jobs run in stages?
Stages give the pipeline order and fail-fast behaviour. Jobs in one stage run in parallel, and the next stage starts only if the current one passes. Ordering build before test before deploy means broken code is caught early and never deployed.

How do I make deploy run only on main?
Use a rule that matches the default branch, such as if: $CI_COMMIT_BRANCH == "main". The generated deploy job is already guarded this way so it does not fire on every feature branch or merge request. Add when: manual to require a click before deploying.

Do I need to set up a runner?
GitLab.com provides shared runners, so cloud-hosted projects work out of the box (within included minutes). Self-managed GitLab or private build needs require registering your own runner. Either way the .gitlab-ci.yml is the same; the runner just executes the jobs.