.gitlab-ci.yml from your project's language, pipeline stages, and a deployment branch. The generated pipeline is legible, cache-aware, and follows standard GitLab CI idioms without any server-side dependency.GitLab CI YAML Generator
Pick an image and pipeline shape — copy a ready-to-commit .gitlab-ci.yml.
Runs entirely in your browser — YAML is generated locally on demand.
Jobs can run in parallel within a stage. The pipeline runs build, then test, then deploy (if a deploy command is set).
rules: restrict test to your default branch and deploy to the deploy branch, so merge-request pipelines can stay fast.
Commit as .gitlab-ci.yml in the repository root.
Node: install with npm ci, test with npm test, lint with npm run lint.
See the .gitlab-ci.yml keyword reference at docs.gitlab.com for includes, needs, and parent-child pipelines.
0
lines
0
bytes
0
jobs
.gitlab-ci.yml
About GitLab CI YAML Generator
Assemble a working
Features
Node, Python, Java/Maven, Java/Gradle, Ruby, Go, and .NET images,Configurable stages: build, test, deploy, plus optional lint,Branch-aware rules for test and deploy jobs,Correct cache paths per toolchain,Auto-generated job names and image versions
How to Use
1. Pick your language/image. 2. Set default and deploy branch names. 3. Toggle the lint stage and cache if not wanted. 4. Copy the YAML into .gitlab-ci.yml at the root and push.
Examples
A Node pipeline with cache for .npm, a test job running npm ci and npm test, and a deploy job gated to main. A Python pipeline with pip cache and a pytest test job. A Maven pipeline caching ~/.m2/repository.
Benefits
Ships a correct pipeline in seconds, with the same structure across languages, so onboarding a new project or language never starts from an empty YAML.
Frequently Asked Questions
Is the generated YAML uploaded anywhere?
No. The generator runs entirely in your browser. Your project language, stages, and image choices are assembled into YAML locally and shown for you to copy.
Where does this file live?
Commit it as .gitlab-ci.yml at the repository root. GitLab reads it on every push and schedules the pipeline automatically.
What default image is used?
Toolchain-specific Docker images, for example node:20-bookworm for Node, python:3.12-slim for Python, maven:3.9-eclipse-temurin-17 for Java/Maven, ruby:3.3 for Ruby, golang:1.22 for Go, and mcr.microsoft.com/dotnet/sdk:8.0 for .NET.
What stages does it produce?
A sensible pipeline: build, test, and deploy (deploy only when the branch matches a deployment branch you set). You can add a lint stage as an option.
How does caching work in the generator?
Each job includes a cache: block keyed to the runner OS with the standard path for the toolchain, such as .npm, .cache/pip, or .m2/repository.
Can I target only certain branches?
Yes. The test job can be limited to specific branches via rules, while deploy is limited to the deployment branch you configure.
Does it support only master?
No, the default branch name is configurable, including main. The generated rules reference your chosen default and deploy branches.
Is this also a full GitLab CI reference?
It generates a solid default pipeline. For advanced features such as includes, needs, or child pipelines the YAML comments point you to the GitLab docs.