Pick a template and shape your pipeline with a form: stages, a default image, a lock-file cache, and jobs with scripts, artifacts, JUnit reports, needs and rules. The .gitlab-ci.yml updates as you type and is checked for common mistakes such as unknown stages or broken needs.
Last updated:
.gitlab-ci.yml
Advertisement
Advertisement
How to use the GitLab CI Config Generator
Choose a template such as Node.js, Python or Docker image to start with sensible jobs.
Set the pipeline basics: the list of stages, the default image, the cache and any global variables.
Edit the jobs: name, stage, script lines and when they run. Open More options for services, needs, reports and environments.
Add, duplicate, reorder or delete jobs and watch the stage overview and the YAML update.
Fix any red notes, then copy or download the file and commit it as .gitlab-ci.yml in the repository root.
Key .gitlab-ci.yml keywords
Keyword
What it does
Example
stages
Order in which groups of jobs run
[test, build, deploy]
default
Settings inherited by every job, such as image, cache and interruptible
image: node:20-alpine
variables
Environment variables for all jobs or one job
PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
script
Shell commands the job runs (required)
- npm test
before_script
Commands run before script, in the same shell
- docker login …
services
Extra containers available during the job
postgres:16, docker:27-dind
cache
Files reused between pipelines to save download time
key: {files: [package-lock.json]}
artifacts
Job output passed to later jobs and kept for download
paths: [dist/], expire_in: 1 week
needs
Start as soon as these jobs finish, ignoring stage order
needs: [build]
rules
Decide whether a job is added to a pipeline, and how
- if: $CI_COMMIT_TAG
environment
Track deployments to an environment
name: production
workflow
Rules for whether the whole pipeline is created
Avoid duplicate MR and branch pipelines
Useful predefined CI/CD variables
Variable
Value
$CI_DEFAULT_BRANCH
The project's default branch, usually main
$CI_COMMIT_BRANCH
Branch name in branch pipelines (not set in merge request or tag pipelines)
$CI_COMMIT_TAG
Tag name, only in tag pipelines
$CI_PIPELINE_SOURCE
What started the pipeline: push, merge_request_event, schedule, web…
$CI_COMMIT_REF_SLUG
Branch or tag name made safe for URLs and cache keys
$CI_COMMIT_SHORT_SHA
First 8 characters of the commit SHA, handy as an image tag
$CI_PROJECT_DIR
Full path where the repository is cloned in the job
$CI_REGISTRY_IMAGE
Address of the project's container registry image
Tips for faster, safer pipelines
Pin image versions (node:20-alpine, not node:latest) so a new upstream release cannot break a pipeline overnight.
Use needs to let independent jobs run in parallel instead of waiting for whole stages.
Give artifacts an expire_in so old build output does not fill your storage quota.
Publish test results with artifacts:reports:junit to see failures directly in merge requests.
Keep deploy jobs on the default branch and make production deploys manual until you trust the pipeline.
Frequently asked questions
Where do I put the .gitlab-ci.yml file?
Commit it to the root of your repository with exactly that name. GitLab detects it on the next push and starts a pipeline using the shared or project runners available to the project. You can preview and validate it in GitLab under Build, Pipeline editor.
What is the difference between stages and needs?
Stages run in order: every job in one stage waits until all jobs in the previous stage have finished. needs lets a job start as soon as the specific jobs it lists are done, even if other jobs in earlier stages are still running, which shortens pipelines. A job can only need jobs in the same or an earlier stage.
How does caching differ from artifacts?
A cache speeds up jobs by reusing downloaded dependencies such as .npm or .m2 between pipelines, but it is best-effort and may be missing. Artifacts are the outputs of a job, such as a dist folder or test report, and are reliably passed to later jobs in the same pipeline and kept for download until they expire.
Why use cache:key:files with a lock file?
With key: files, GitLab builds the cache key from the content of the listed files, such as package-lock.json. The cache is reused until the dependencies change, and a new cache is created automatically when they do. You can list up to two files.
What do the workflow rules do?
Without them, pushing to a branch that has an open merge request can start two pipelines: a branch pipeline and a merge request pipeline. The generated workflow rules run merge request pipelines, skip branch pipelines while a merge request is open, and still run pipelines for other branches and tags.
How do I use secrets in the pipeline?
Do not write passwords or tokens in .gitlab-ci.yml. Add them in GitLab under Settings, CI/CD, Variables, mark them as masked and protected, and reference them in scripts as $MY_TOKEN. Predefined variables such as $CI_REGISTRY_USER and $CI_REGISTRY_PASSWORD are provided automatically for the project's container registry.
Why does a job need a script?
Every regular job must have a script section with at least one command; GitLab rejects the configuration otherwise. The only exceptions are trigger jobs that start another pipeline. Hidden jobs whose names start with a dot are templates for extends and do not run.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.