GitLab CI

Pipelines defined in .gitlab-ci.yml with built-in environments and approvals.

adds it to an existing project · no account needed
Currentas published in v1.5.1

The rule

This is the whole text, exactly as your agent receives it. Nothing is held back for the paid tier.

Variables

  • Secrets live in Settings → CI/CD → Variables, never in .gitlab-ci.yml.
  • Mark every secret Masked (hidden in logs) and Protected (available only to protected branches and tags). Both switches matter and they do different things.
  • Never unprotect a variable so a fork merge request can use it — that is the leak the setting exists to prevent.

Pipelines

  • interruptible: true so a new push cancels superseded pipelines.
  • rules rather than the older only/except.
  • Cache keyed on the lockfile, caching the package manager's cache directory — not node_modules itself.

Deployment

  • Production deploys are when: manual, against a protected environment.
  • A green pipeline means the code is safe to ship, not that now is the moment.

Runners

  • Jobs touching production credentials run on project runners, not shared ones.
  • Shared runners execute your job on infrastructure you do not control.

Never

  • Never echo a variable to debug it — that defeats masking.
  • Never commit a credential and rely on history rewriting; rotate it instead.

6 formats, one per tool

Each tab is the file that tool actually reads, at the path it actually looks in. Knowing where each one looks is most of the work of supporting it.

.cursor/rules/gitlab-ci.mdchand-written
---
description: GitLab CI conventions
globs: [".gitlab-ci.yml", "ci/**"]
alwaysApply: false
---

# GitLab CI

## Variables

- Secrets live in **Settings → CI/CD → Variables**, never in `.gitlab-ci.yml`.
- Mark every secret **Masked** (hidden in logs) and **Protected** (available
  only to protected branches and tags). Both switches matter and they do
  different things.
- Never unprotect a variable so a fork merge request can use it — that is the
  leak the setting exists to prevent.

## Pipelines

- `interruptible: true` so a new push cancels superseded pipelines.
- `rules` rather than the older `only`/`except`.
- Cache keyed on the lockfile, caching the package manager's cache directory —
  not `node_modules` itself.

## Deployment

- Production deploys are `when: manual`, against a protected environment.
- A green pipeline means the code is safe to ship, not that now is the moment.

## Runners

- Jobs touching production credentials run on project runners, not shared ones.
- Shared runners execute your job on infrastructure you do not control.

## Never

- Never `echo` a variable to debug it — that defeats masking.
- Never commit a credential and rely on history rewriting; rotate it instead.

Hand-written by the module author, frontmatter and all. It is the source the four derived formats are rendered from, so a correction lands here first.

What else this module writes

The rule is one file of several. Selecting GitLab CI contributes all of this too — merged with every other module you pick, with conflicts resolved rather than duplicated.

Environment
CIoptionalSet by the runner. Use it to skip prompts and enable machine-readable output.

Advisory history

Every time this rule turned out to be wrong, and what we did about it.

No corrections yet

This rule has been accurate since it was published. That is a fact about the rule, not a promise about the future — which is the whole reason this section exists.

Pro tells you the day a correction lands that affects a repo you actually have.

See what Pro adds →

Rules people add alongside this one

conflicts withGitHub Actions
Put this rule in a real project

The wizard picks the rest of the stack with you, writes all 6 formats, and leaves a manifest so check can tell you when any of it drifts.