How to skip a GitLab CI pipeline: [skip ci], ci.skip and workflow rules

A typo fixed in the README, a version bump, a change to the docs: not every push needs the whole pipeline. GitLab can skip one for a single push, for a merge request, or by rule in .gitlab-ci.yml. Here is how each way works in 2026, and what each one doesn’t skip.

Skip the pipeline for one push

Add [skip ci] or [ci skip] to the commit message:

git commit -m "Fix typo in README [skip ci]"
git push

• Anywhere, in any case. The subject line or the body; [skip ci], [Skip CI] or [CI SKIP]. GitLab’s code also accepts a hyphen or an underscore, as in [skip-ci] or [ci_skip], though the docs list only the spellings with a space.
• The last commit counts. GitLab reads the message of the newest commit in the push. Push three commits with [skip ci] in the first one only, and the pipeline runs.
• It leaves a trace. GitLab records an empty pipeline, with no stages or jobs, and the status Skipped (skipped in the API).
• Tags inherit it. A tag pipeline runs on the tagged commit, and GitLab reads that commit’s message, so tagging a [skip ci] commit skips the tag’s pipeline too. If you’ll tag the commit later, skip with the push option below instead.

Skip it without changing the commit

A push option skips the pipeline for that push only:

git push -o ci.skip

• The commit stays as it is, so a later push, or a tag on the same commit, runs a pipeline as usual.
• GitLab documents it for branch pipelines, not merge request pipelines. For those, use the title, below.
• CI/CD integrations still get the push. It doesn’t skip Jenkins, TeamCity and the like; git push -o integrations.skip_ci does.

More push options, such as opening a merge request in the same push, are in create a GitLab merge request from the command line.

Skip merge request pipelines

Since GitLab 19.5, put [skip ci] or [ci skip], in any capitalization, in the merge request’s title:

• It skips basic merge request pipelines, merged results pipelines and merge train pipelines, also when the merge request has conflicts.
• They stay skipped until you take it out of the title; then select Run pipeline on the merge request’s Pipelines tab. On GitLab 19.5, a merged results pipeline can stay skipped until your next push, because the merge commit GitLab tests still carries the old title.
• Added while the merge request is on a merge train, it takes the merge request off the train, because a skipped pipeline isn’t a successful one.
• It sits behind the ci_skip_pipeline_from_mr_title feature flag, which is on by default.

In your last commit’s message, [skip ci] also skips a basic merge request pipeline, which runs on that commit. A merged results pipeline runs on a merge commit GitLab builds, so put the directive in the title for those.

Skip pipelines by rule

workflow:rules in .gitlab-ci.yml decide whether GitLab creates a pipeline at all. This one skips merge request pipelines while the merge request is a draft. If you already have workflow:rules, add its first rule at the top of them instead of pasting the whole block:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_DRAFT == "true"
      when: never
    - when: always

• CI_MERGE_REQUEST_DRAFT arrived in GitLab 17.10. On older versions, match CI_MERGE_REQUEST_TITLE with a regular expression. More in GitLab draft merge requests.
• Marking the merge request ready doesn’t start a pipeline by itself: push, or select Run pipeline on its Pipelines tab.
• A rule can match the commit message as well, such as if: $CI_COMMIT_MESSAGE =~ /-draft$/ with when: never.
• Unlike [skip ci], a when: never rule leaves no skipped pipeline behind: GitLab doesn’t create one.

What [skip ci] doesn’t skip

• Pipelines you start from Build › Pipelines. Run pipeline there, the pipelines API, pipeline schedules and trigger tokens run whatever the commit message says. That’s also the way to run a tag’s pipeline after all. Run pipeline on a merge request’s Pipelines tab is different: it’s skipped again while the title, or for a basic pipeline the last commit, says [skip ci].
• Pipeline execution policies. Where one applies, [skip ci] is ignored unless the policy allows it. Scan execution policies can restrict it too.
• CI/CD integrations. GitLab still sends Jenkins, TeamCity and the like the push, and whether they build is up to them; -o integrations.skip_ci holds it back.

A skipped pipeline can block the merge

With Pipelines must succeed turned on, a skipped pipeline keeps a merge request from merging. To let it through, a Maintainer or Owner opens Settings › Merge requests and, under Merge checks, selects Skipped pipelines are considered successful as well. Auto-merge waits for a successful pipeline too, so it stalls on a skipped one unless that setting is on.

workflow:rules can also leave a merge request with no pipeline at all. With Pipelines must succeed on, it then keeps showing “Checking pipeline status.” and can’t merge. The other blockers are in why can’t I merge my GitLab merge request?

Skipped pipelines on your phone

MergeBell shows a skipped pipeline as Skipped, and when the project needs a successful one, the merge request’s overview gives the reason: “The pipeline has to pass.” Live job logs, retry, cancel and manual jobs are on the free tier, on iPhone and Android, and with Pro a pipeline watch sends a push when a branch’s pipeline fails. When a job does fail, see how to retry a failed GitLab pipeline.