GitLab CI Generator
Create a .gitlab-ci.yml for your project with GitLab’s best practices built in: one pipeline per merge request, the language image as default, dependency caching keyed by the lock file, lint, test and build jobs, a database service for tests, JUnit reports in merge requests, container images built with Kaniko or Docker-in-Docker, and a manual deployment to a protected environment.
- Runs in your browser
- No sign-up
- Free to use
How to use GitLab CI Generator
- Choose the language and version.
- Adjust install, lint, test and build commands.
- Add a database service, image build or deployment.
- Commit the file as .gitlab-ci.yml.
GitLab CI Generator features
Stages
test, build, package and deploy, created as needed.
Caching
Dependency cache keyed by the lock file.
Workflow rules
No duplicate branch and merge-request pipelines.
Services
PostgreSQL, MySQL or Redis with test credentials.
Images
Kaniko (no privileged runner) or Docker-in-Docker.
Deployments
Manual job with environment and resource group.
When to use GitLab CI Generator
- Setting up CI for a new GitLab project.
- Building container images into the GitLab registry.
- Adding a protected manual deployment step.
- Migrating a project from another CI service.
GitLab CI Generator FAQ
What do the workflow rules do?
They run a merge-request pipeline for merge requests and a branch pipeline otherwise, so the same commit does not run twice.
Why Kaniko?
Kaniko builds images without a Docker daemon, so it works on shared runners without privileged mode. Docker-in-Docker needs privileged = true.
Where do credentials come from?
Registry access uses GitLab’s predefined CI_REGISTRY variables. Deployment credentials belong in protected, masked CI/CD variables.
What is resource_group?
It makes jobs in the same group run one at a time, so two deployments to production never overlap.
How do test reports appear?
When the test command writes JUnit XML (for example pytest --junitxml=report.xml), the job uploads it and GitLab shows the results in the merge request.
Is anything uploaded?
No. The file is generated in your browser.
Pipelines in GitLab
GitLab CI/CD reads the pipeline definition from .gitlab-ci.yml at the root of the repository. Jobs belong to stages that run in order, each job runs in a container image on a runner, and keywords such as cache, artifacts, services and rules control what happens between and around them.
The generator sets the language image as the default for all jobs and caches the package directory with a key derived from the lock file, so the cache stays valid until dependencies change. Linting and tests run in the test stage, the build stage keeps its output as artifacts for a week, and later stages can use them.
Workflow rules decide when pipelines run at all. The generated rules create merge-request pipelines for merge requests and branch pipelines for other pushes, avoiding the common problem of two identical pipelines per commit. Jobs are interruptible, so a newer pipeline can cancel an outdated one.
Container images can be built in two ways. Kaniko runs as an ordinary container and pushes to the project’s registry with the predefined credentials. Docker-in-Docker uses the docker CLI and needs a privileged runner. Both tag the image with the short commit SHA.
Deployments run on the default branch only, wait for someone to start them, record an environment for GitLab’s deployment history and use a resource group so they never overlap. Keep deployment credentials in protected, masked variables.