GitLab CI Configuration Generator for Pipelines
Most teams inherit a pipeline file that was copied from another project, with stage names that stopped matching reality and a cache block nobody remembers adding. This page builds .gitlab-ci.yml from the fields you fill in: start from a preset or keep the default build and test stages, adjust the image and variables, describe each job in its own card, then press Build YAML.
Every card carries the parts GitLab reads when a pipeline starts: the stage the job joins, the container image, one script command per line, a rules block, a cache key, artifact paths, and job-level variables. Validation runs before any text reaches the output box, so a job pointed at a stage you never declared or a variable name starting with a digit shows up in the list under the button while the output stays empty.
The file is assembled inside this tab, so no request carries your settings anywhere and no account is involved. Copy the result with one button or download it as gitlab-ci.yml and commit it at the repository root.
Configure Stages and Jobs, Then Build the YAML
Start from a preset
Loading a preset fills the fields and the job cards below. It does not build anything until you press Build YAML.
Pipeline defaults
Jobs
One card per job, with a single script command on each line.
How It Works
- Fill the defaults first. The default image goes into a default block, the stages box is split on commas with blanks dropped, and each global variable line is split at the first equals sign into a key and a value.
- Describe every job in its own card. Name, stage, image, script lines, rules text, cache key, artifact paths, and job variables are read from the cards when you press Build YAML, and each field writes back to the page state as you type.
- Validation runs before assembly. Stage lists, job names, job stages, script lines, and variable names are all checked, and every problem appears verbatim in the red list beneath the summary line.
- A clean run assembles the file in a fixed order: stages, then global variables, then the default image, then each job with its stage, image, variables, script, cache, artifacts, and rules.
The rules box holds raw YAML lines rather than a structured form. Each non-empty line becomes one rules entry in the output, with the list dash written for you, so a line such as - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH comes out as a single condition and a second line becomes a second condition. The same applies to artifact paths: one box, split on spaces or commas into separate path entries.
When validation passes, the text lands in the output box, the summary counts the jobs and stages it saw, and the download link receives a local blob address for gitlab-ci.yml. A later run with problems empties the output box and revokes that address, so the previous file can no longer be downloaded by accident.
Before and After
stages: build,test
build:
stage: build
script: npm ci
test:
stage: test
script:
- npm test
variables RELEASE=truestages:
- "build"
- "test"
variables:
CI: "true"
default:
image: "node:20-alpine"
build:
stage: build
image: "node:20-alpine"
script:
- "npm ci --cache .npm"Use Cases
| Developer | Production | Workflow |
|---|---|---|
| Add a first pipeline to a new service repository | Keep stage names consistent across a fleet of repositories | Review a merge request that edits .gitlab-ci.yml |
| Set up a Pages deploy job for a documentation site | Give every team the same cache and artifact layout | Move a project from ad-hoc scripts to gated stages |
| Check rules syntax before pushing a change | Standardize image builds across shared runners | Hand a new maintainer a starter pipeline that runs |
Common Mistakes
- Committing the file under a different name. GitLab reads .gitlab-ci.yml at the repository root, so a file called ci.yml or a copy inside a subfolder does nothing until the CI/CD configuration path setting points at it.
- Typing a stage on a job that the stages box never declared. The build stops with a quoted message naming both the job and the missing stage, which is quicker to fix than reading the whole file for a mismatch.
- Stacking extra keys under one rule line. Each non-empty rules line is written as its own entry, so a continuation line such as when: manual turns into a second rule instead of a second key; split the conditions across lines instead.
- Leaving a job with an empty script and hoping GitLab skips it. An empty script fails the job the moment it runs, and the validator repeats that warning until at least one command line is typed.
Best Practices
- Keep the stage list short and ordered, usually build, test, then deploy. Jobs in one stage share a runner pool, and a reversed order spends runner time on work a later failure would throw away.
- Put shared values such as registry paths and version pins in the global variables box, then override them on single jobs where a job needs a different value. Scripts read them as $KEY at run time.
- Give cache keys a name that matches the toolchain, such as npm or pip, and use a separate key for any job whose folder must not be shared with another job.
- List only files a later stage really needs under artifact paths. Every entry is stored and transferred after the job, so shipping node_modules as an artifact bloats the pipeline without helping the deploy stage.
Frequently Asked Questions
Where do I put the generated file?
Commit it at the root of your repository under the exact name .gitlab-ci.yml, leading dot included. GitLab looks there by default and starts a pipeline on the next push or merge request, while a file with a different name or folder is skipped. If your project keeps CI files elsewhere, change the CI/CD configuration path in the repository settings to match.
What do stages do and in what order should I list them?
Stages are the phases a pipeline moves through, listed in the order they run. Jobs inside one stage start in parallel, and the following stage begins only after every job in the current stage passes. A common order is build, then test, then deploy, so work that fails early never reaches the step that publishes it.
How does a job decide which stage it runs in?
The stage field on the job card names it, and that name has to match an entry in the stages box exactly. The validator catches a mismatch and prints the pair, for example Job "unit" uses stage "testing" which is not in the stages list. The position of a job inside the file does not set the order; the stages list does.
What does the rules block control?
Rules decide when GitLab adds a job to a pipeline, based on the branch, the triggering event, or a schedule. The line - if: $CI_PIPELINE_SOURCE == "merge_request_event" in the rules box keeps a job out of branch pipelines and runs it only for merge requests. Keep one condition per line, since every non-empty line in the rules box comes out as its own entry.
How do variables work in this file?
Each KEY=VALUE line in the global box becomes a pipeline variable, and lines typed on a job card become variables scoped to that one job. Scripts read them at run time in shell form, so a command such as docker build -t "$IMAGE_TAG" expands inside the container before it runs. A variable name starts with a letter or `_`, then carries letters, digits, and `_` only.
What are cache and artifacts for?
A cache key tells GitLab to carry a folder from one run of a job to the next, which shortens dependency installs on later pipelines. The generated cache block stores .cache/, so place tool files there in the script when you want them reused. Artifacts work differently: they are files handed forward to jobs in later stages, such as a build output that a deploy job publishes.
Does my configuration leave the browser?
No. The fields are read into a local object, checked, and joined into text inside this tab, and no request carries any of it away. Copy the output or download gitlab-ci.yml yourself, and closing the page discards the rest.