Job gitlab-ci-job-never-starts-on-merge-request · revised 11 October 2026
Make a GitLab CI job that never starts actually run on a merge request
The named GitLab CI job starts and finishes on a merge request pipeline on a runner you agreed, after we correct the pipeline rules or tags, or give your admin the exact runner setting to change.
You might be seeing
- The Pipelines tab of a merge request is empty or shows a pipeline without the job you expect
- A job stays pending and is eventually dropped, with a stuck or no-matching-runner reason
No passwords, keys, card details or admin invites needed to start.
What usually happened
The job is never offered to a runner. The pipeline rules may exclude merge request pipelines, the job's tags may name a tag that no runner has, a runner may be restricted to protected branches, tagged-only or offline, or both a push pipeline and a merge request pipeline may exist and the wrong one is configured. The job never fails, because it never starts, so there is no log to read.
Who it’s for: A small team on GitLab whose merge request shows no pipeline, or a job that sits in pending until it is dropped, so nothing can be reviewed or merged.
Usually starts when: A merge request has no pipeline, or the named job stays pending with a message that it is stuck or has no matching runner.
The result: The named job starts and finishes on a runner that carries the agreed tags in a merge request pipeline on a test branch, and the pipeline appears once, not twice. Where a runner setting must change, you receive the exact setting for your administrator and the job runs after they apply it.
Check whether this job fits
Look at the merge request and the job's page. The wording tells a missing pipeline from a pending job.
Checks you can run yourself
Read the job's tags and the runner tags side by side
Copy the tags line from the job in the pipeline file and open the project's runner list. Do not edit anything.
Look for: Whether a runner carries every tag the job lists, whether it is online, whether it runs untagged jobs and whether it is limited to protected branches.
What you get
- A merge request with the pipeline-file change and a note naming the cause
- If a runner setting is needed, a written change request for your administrator naming the setting and the expected effect
- Links to the pipeline and job that started, with the runner and tags shown
- Steps to revert the change
Included
- One job, or one chain of jobs, in one GitLab project's pipeline file
- Read the pipeline rules, the job's tags and the runner list visible to you, and identify why the job is not created or not picked up
- Correct the pipeline rules or job tags with the smallest change in the pipeline file
- Where the cause is a runner setting, write the exact change for your administrator, who applies it
- Run a merge request pipeline on a test branch and record the result
Not included
- Installing, registering or repairing runners or their hosts
- Changing runner, group or instance settings ourselves
- Jobs that start and then fail: not covered by a fixed-price outcome, so ask for a quote (the single-job repair is for GitHub Actions only)
- Migrating the project to or from another CI system
- Billing, compute-quota or licence problems on the platform
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On a test merge request, the named job appears in the pipeline, is picked up by a runner that carries every tag the job lists, and finishes.
Evidence: The pipeline and job links, showing the runner name and tags.
One pipeline is created for the test merge request event, not two.
Evidence: The merge request's Pipelines list after one push, with the pipeline types shown.
No job was removed, disabled or made to ignore failure, and no rule change widens when deploy jobs run.
Evidence: The reviewed diff and the pipeline's job list before and after.
Your authorised maintainer accepts the evidence and merges the change; if a runner setting was needed, your administrator confirms it was applied.
Evidence: Your written sign-off and the merged merge request record.
Sign-off. You inspect the pipeline, the runner evidence and the diff, sign off in writing and merge the change. Payment follows sign-off.
If it fails. If the job does not start on an agreed runner, you do not pay for this fixed scope. If the cause is a missing runner, a quota or a fork policy, we explain it with the evidence and stop; wider work needs a new written agreement.
When it fits, and when we stop
It fits when
- You can open the project's pipeline file and the merge request, and see the runner list in the project's settings or ask someone who can
- A test branch and merge request can be created without deploying
- Your administrator can apply a runner setting if one is needed
- Your maintainer can review and merge the change
We stop and tell you if
- No runner is registered for the project and none can be provided: we explain what is missing and stop
- The pending job is caused by a quota, licence or billing restriction
- The merge request comes from a fork whose pipeline policy you cannot change
- The job would deploy or use protected secrets on the test branch
What could go wrong
Before merge, closing the merge request leaves your default branch unchanged. After merge, your maintainer can revert the commit. A runner setting your administrator changed is reverted by them using the note we supply.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A rule change makes pipelines run for events that should not trigger deploys. | We change rules only for the named job, read every other job's rules and stop if a deploy job would start on a test branch. |
| A runner is widened so that untrusted merge requests use protected resources. | We never ask for a protected runner to be opened to unprotected branches; the change request names the least setting needed. |
| The pipeline now runs twice for one push. | Acceptance requires a single pipeline per event, and the reviewer checks the workflow rules. |
An independent reviewer checks that the job really ran on the agreed runner rather than being excluded, that no job was removed to make the pipeline pass and that the merge request does not create duplicate pipelines. Your maintainer and administrator hold the final changes.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the project, the job, the test branch and the person who can apply a runner setting, in writing
- Read the rules, tags and runner information and decide whether the job is not created or not picked up
- Reproduce the missing pipeline or pending job on a test merge request and record it
- Correct the rules or tags with the smallest change, or write the exact runner setting for your administrator
- Run a merge request pipeline on the test branch and record the job starting on the agreed runner and the pipeline appearing once
- Have an independent reviewer check the evidence and the diff, then hand over the merge request and revert notes
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and necessary permissions are in place. Platform, runner and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
If pipeline rules keep drifting as the project grows, ask us about ongoing cover; there is no fixed-price standing service for GitLab yet.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- GitLab documents how a job's tags must all match a runner's tags and how a runner can be limited to protected branches or tagged jobs only. Your administrator can check both before buying anything. docs.gitlab.com
- GitLab documents the conditions a pipeline file needs for merge request pipelines to run, including that rules defined only in included files do not satisfy them. docs.gitlab.com
- GitLab's job rules page explains how one push to a branch with an open merge request can start both a push pipeline and a merge request pipeline, and how to avoid the duplicate. docs.gitlab.com
Questions
Will you change our runners?
No. We write the exact setting for your administrator to apply. We never hold runner tokens or administer your runners.
What if we have no runners at all?
Then this fixed job cannot start work. Someone must provide a runner first, and we say so rather than guess.
Is this the same as the GitHub Actions job repair?
No. The GitHub Actions job repair covers GitHub only. This covers a GitLab job that is never created or never picked up. A GitLab job that starts and then fails is not covered by a fixed-price outcome; ask for a quote.
Send an enquiry
Send us
- The job name, the line that lists its tags, and a plain-words description of when it should run; do not attach the pipeline file
- Whether the project uses shared runners, project runners or both, and the tags they carry if you can see them
- What the merge request shows: no pipeline, a pipeline without the job, or a pending job and its message
- Do not send credentials, runner tokens, source code or an access invitation in the first enquiry
Later, once you agree
- The pipeline file through an authorised company-controlled route, with a branch for the merge request
- Read access to pipeline and runner information with the least access needed
- The name of the administrator who will apply any runner setting, and who reviews and merges
You own the project, the runners and the settings. We read the authorised pipeline file and the runner information you share, and work on a branch through a company-controlled identity, never a personal login. Your administrator applies any runner setting. We never hold runner tokens.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “gitlab-ci-job-never-starts-on-merge-request” as the subject.