🚨 GitLab CI Error Guide: 'Pipeline cannot be run' No Pipeline Created Fix

Exact Error Message

A commit or merge request produces no pipeline, and depending on where you trigger it you see one of:

Pipeline cannot be run.

No pipeline created

An error occurred while trying to run a new pipeline for this merge request.

Often there is no error at all — the commit simply shows no pipeline status, and the Pipelines list stays empty for that ref. CI Lint may even report the config as valid.

What the Error Means

GitLab decides whether to create a pipeline at all before it decides which jobs to run. That gate is workflow:rules (plus project-level pipeline settings). If workflow:rules matches no rule — or matches a rule whose result is when: never — GitLab creates zero pipelines. Separately, even when a pipeline is allowed, if every individual job is excluded by its own rules/only/except, the pipeline would have no jobs and is not created either.

So “no pipeline” almost always means a rule excluded everything, not that your YAML is broken. The config can lint clean and still produce nothing, because linting validates structure, not whether the current event satisfies your rules. The fix is to make sure some rule matches the event (CI_PIPELINE_SOURCE, branch, MR) you are actually triggering.

Common Causes

1. workflow:rules dropped every pipeline. The rules list has no matching if, or its catch-all is when: never, so nothing is created.
2. All jobs excluded by rules/only/except. workflow allows the pipeline, but every job is filtered out, leaving nothing to run.
3. Branch vs merge-request (detached) confusion. Rules key on CI_PIPELINE_SOURCE == "merge_request_event" but you pushed a branch, or vice versa, so neither path matches.
4. .gitlab-ci.yml is not on that branch. The branch you pushed has no CI config (or a different one), so GitLab has nothing to evaluate.
5. Branch pipelines disabled / CI/CD disabled. Project settings turn off pipelines, or the feature is disabled entirely.
6. Missing catch-all. workflow:rules lists specific cases but no final fall-through, so unanticipated events get no pipeline.

How to Reproduce the Error

A workflow:rules that only allows main silently drops every other branch:

workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
    # no catch-all -> every other ref creates no pipeline

build:
  stage: build
  script: ["make build"]

Push a feature branch and nothing appears in Pipelines — no error, no jobs.

A mismatch on pipeline source does the same:

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

test:
  script: ["make test"]

A plain branch push (CI_PIPELINE_SOURCE == "push") matches no rule, so no branch pipeline is created.

Diagnostic Commands

Lint the config — note that a valid result does not mean a pipeline will be created:

glab ci lint

✓ Configuration is valid

Check the predefined variables your rules key on, for the event you are triggering:

CI_PIPELINE_SOURCE = push           # branch push
CI_PIPELINE_SOURCE = merge_request_event
CI_PIPELINE_SOURCE = web            # "Run pipeline" button
CI_PIPELINE_SOURCE = schedule
CI_COMMIT_BRANCH   = feature/login  # set for branch pipelines, empty for MR pipelines
CI_COMMIT_REF_NAME = feature/login

Confirm .gitlab-ci.yml actually exists on the branch you pushed:

git show "$CI_COMMIT_REF_NAME:.gitlab-ci.yml" | head

In the UI, open Project > Build > Pipeline Editor, then the Validate tab and the Full configuration view, and check Settings > CI/CD > General pipelines to confirm pipelines are enabled and not restricted. The Pipeline Editor’s “Validate” run lets you simulate a branch or MR source.

Step-by-Step Resolution

Add a catch-all to workflow:rules so unanticipated events still create a pipeline (or are explicitly, deliberately skipped):

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: '$CI_COMMIT_TAG'
    - when: always          # final catch-all: create a pipeline for anything else

If you intentionally want to suppress some events, make the catch-all explicit (when: never) so the behavior is documented, not accidental.

Fix CI_PIPELINE_SOURCE conditions to match how you actually trigger. To support both MR pipelines and branch pipelines without duplicating them, guard against double pipelines:

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
      when: never          # avoid duplicate branch+MR pipelines
    - if: '$CI_COMMIT_BRANCH'

Align job-level rules with workflow. Even with a valid workflow, a pipeline is not created if every job is excluded. Make sure at least one job matches:

test:
  stage: test
  script: ["make test"]
  rules:
    - if: '$CI_COMMIT_BRANCH'     # runs on branch pipelines

Confirm the config is on the branch and pipelines are enabled. Commit .gitlab-ci.yml to the branch you push, and in Settings > CI/CD ensure pipelines are enabled and the CI/CD feature is on for the project.

After each change, push (or use Run pipeline / the Pipeline Editor Validate) and confirm a pipeline now appears with at least one job.

Prevention and Best Practices

• Always end workflow:rules with an explicit catch-all (when: always or a documented when: never) so no event silently produces nothing.
• Key rules on CI_PIPELINE_SOURCE and decide deliberately between branch pipelines, MR pipelines, or both — and guard against duplicate pipelines.
• Remember that a valid CI Lint result does not guarantee a pipeline is created; rules decide that separately, so test the actual event.
• Keep .gitlab-ci.yml on every branch that should run CI, and verify project pipeline settings are enabled before debugging YAML.
• Use the Pipeline Editor’s Validate tab to simulate a branch or MR source, and the merged-YAML view to confirm at least one job survives rules.
• The free incident assistant can suggest why an event produced no pipeline; more patterns live in the GitLab CI/CD guides.

Related Errors

• job needs job, but it was not added to the pipeline — a pipeline is created, but a needs: target was filtered out.
• Invalid CI config / YAML validation errors — a structurally broken config, distinct from a config that lints fine but creates nothing.
• Included file does not exist! — a broken include can leave the merged config with no jobs to run.

Frequently Asked Questions

My CI Lint says the config is valid, so why is there no pipeline?

CI Lint validates structure, not whether the current event satisfies your rules. workflow:rules (and job rules) decide whether a pipeline is created, and they are evaluated against the real event — branch, tag, MR, schedule. A valid file can still match no rule and create nothing.

How do I make sure every push gets a pipeline?

End workflow:rules with - when: always, and ensure at least one job has rules that match a branch push. The catch-all guarantees the pipeline is created; the matching job guarantees it has something to run.

Why does my merge request say “An error occurred while trying to run a new pipeline”?

Usually the MR’s source/target combination matches no workflow rule, or every job is excluded for merge_request_event. Add a rule for $CI_PIPELINE_SOURCE == "merge_request_event" and confirm at least one job runs for it.

I get two pipelines per push — how is that related?

That is the opposite symptom of the same area: both a branch pipeline and an MR pipeline are created. Add a when: never rule for $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS to suppress the duplicate, keeping a single pipeline per event.

Could project settings be the cause rather than my YAML?

Yes. If pipelines or CI/CD are disabled in Settings > CI/CD, no pipeline is created regardless of your rules. Confirm the feature is enabled and that .gitlab-ci.yml exists on the branch before debugging the rules.