What this builder does
A .gitlab-ci.yml lives at the root of your GitLab repo and describes the full pipeline: ordered stages (install, test, deploy), individual jobs with their scripts, what to cache and what to publish as artifacts, and when each job actually runs (only on main? only on tags? only when a file changed?). It is one file, no separate UI, version-controlled with the rest of the code.
This builder writes that file for you. Pick a preset (test + deploy, Docker registry push, GitLab Pages), edit stages and jobs in forms, and the right pane shows the exact YAML you can drop into `.gitlab-ci.yml`. The validator checks the common traps: a job needing another job in a later stage, a job referencing a stage that is not in the `stages:` list, duplicate job names, jobs without a script.
Everything runs in your browser. No upload, no account, no real pipeline is started here. The output is the same text you would write by hand.
How to use it
- Pick a preset at the top: Test + deploy, Docker registry push, or GitLab Pages. The form fills in sensible defaults.
- Set the default image (used by every job that does not override it), the ordered list of stages, and any global variables as `KEY=value` pairs.
- Add jobs in tabs. For each job set: a unique name, the stage it belongs to (must match one in the stages list), an optional image override, optional variables, and needs.
- Write the script (one command per line). Optionally add a before_script for setup commands shared across runs.
- Set artifacts (paths and `expire_in`) for the build output. Set cache with a key and paths to speed up repeated runs.
- Add rules with `if:` expressions, e.g. `$CI_COMMIT_BRANCH == "main"`. Pick `on_success`, `always`, `manual` (requires a click to start), or `never`.
- Toggle allow_failure for jobs that should not block the pipeline if they fail (linters, security scanners that are advisory).
- Click Copy in the preview pane, or Download to save as `.gitlab-ci.yml`, then commit it to the root of your repository. The next push triggers the pipeline.
When this is useful
Seven concrete situations where a GitLab CI builder saves real time:
- First pipeline in a new project. Pick "Test + deploy", change the test command, commit. Done in two minutes instead of fishing through the long GitLab docs.
- Adding a Docker registry push to an existing pipeline. The login + tag + push dance is a known sequence; the builder writes it and you only fill the image name.
- Setting up a deploy job that only runs on main. The `rules:` syntax with `if:` is the modern way (replacing the old `only:` / `except:`), and small typos waste a full pipeline run.
- Caching node_modules or pip across pipeline runs. The cache stanza is short but easy to misformat. The builder writes a working cache by default with the standard `$CI_COMMIT_REF_SLUG` key.
- Multi-stage pipeline with parallel jobs in test. Several jobs in the `test` stage run in parallel automatically. The builder makes the structure obvious so you do not accidentally serialize them.
- A manual deploy gate. Set the deploy job's rule to `when: manual` and only an explicit click in the GitLab UI starts the deploy. Common pattern for prod.
- GitLab Pages site deploy. The special `pages` job has to publish to `public/` as an artifact. The "Pages deploy" preset encodes that convention exactly.