GitLab CI/CD Generator

GitLab CI/CD is a continuous integration and continuous delivery platform built into GitLab. Pipelines are defined using a .gitlab-ci.yml file placed in the root of your repository. That single file declares the stages a pipeline runs, the jobs inside each stage, the commands each job executes, and the conditions under which jobs run.

When you push to GitLab, it reads the file and hands each job to a GitLab Runner, an agent that executes the job inside a container. Shared runners are available on GitLab.com with usage limits, or you can install self-managed runners on your own infrastructure. Because jobs run in containers, the image: key selects the exact toolchain for a job, so a PHP job and a Node.js job can each get an appropriate environment.

This generator creates production-ready configurations for common languages and frameworks. The generated YAML follows GitLab conventions including dependency caching, artifact handling, a manual deployment gate, and optional review-app environments.

How the pipeline is structured

• stages — an ordered list. All jobs in a stage finish before the next stage begins, so a failing test blocks the build.
• jobs — named blocks such as lint:, test:, and build:. Each job declares a stage and a script.
• before_script — commands that run before every job, typically installing dependencies.
• cache — persists directories such as node_modules/ or vendor/ between pipelines to speed up installs.
• artifacts — files produced by a job that are kept and can be passed to later stages.
• environment — ties a deploy job to a named environment such as production or a review app.

The test stage is always included, since a pipeline without tests is rarely useful. Lint, build, and deploy are optional toggles.

1. Select Language — Choose your project language or framework from the dropdown.
2. Configure Stages — Toggle which CI/CD stages to include: lint, test, build, and/or deploy.
3. Set Options — Enable caching, artifacts, review apps, and set the deployment branch.
4. Copy or Download — Use the copy button or download the .gitlab-ci.yml file and place it in your project root.

Each stage runs a language-appropriate command. The table below shows what the generator emits for the npm/Node.js and PHP examples; other languages follow the same pattern with their own toolchain.

Go caches .go-cache/ and Rust caches target/. Python and Docker configurations do not emit a cache block by default.

For a Node.js project with lint, test, and build enabled, caching on, and a manual deploy, the generator produces something like this (abridged):

stages:
  - lint
  - test
  - build
  - deploy

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

before_script:
  - npm ci --cache .npm --prefer-offline

test:
  stage: test
  image: node:22
  script:
    - npm test

deploy:
  stage: deploy
  image: alpine:latest
  script:
    - echo "Add your deploy commands here"
  environment:
    name: production
  only:
    - main
  when: manual

Deployment is deliberately gated with when: manual and restricted to a single branch, so a merge never ships to production without a deliberate click.

• Migrating to GitLab — bootstrap a pipeline when moving a project from another CI provider.
• Standardising team pipelines — generate a consistent baseline across many repositories.
• Adding caching — cut pipeline time by caching dependency directories between runs.
• Review apps — spin up a throwaway environment per merge request and tear it down automatically.
• Learning the format — see a working, conventional .gitlab-ci.yml to adapt.