GitLab job never starts: tell a missing pipeline from a job no runner will take

Two faults that look the same

Both show as a merge request where the check you expect never appears, so they are easy to confuse. In the first, no pipeline is created at all, or it is created without your job. In the second, the pipeline exists and the job sits pending until GitLab gives up. Neither produces a log, because nothing ran. The fix differs completely, so the first task is to find out which one you have: open the merge request's Pipelines tab, then the job's page.

Fault one: the job is not created

GitLab evaluates rules in order until the first match. If no rule matches, the job is simply not added to that pipeline, and if workflow rules exclude the event, the whole pipeline does not run. For merge request pipelines specifically, the main pipeline file must contain job or workflow rules that match a merge request event. Rules that live only in an included file do not count for this purpose, which surprises teams that keep all their pipeline definitions in shared includes.

The opposite problem is a duplicate. A push to the source branch of an open merge request can start both a branch pipeline and a merge request pipeline. Narrow rules, or workflow rules that choose which type runs, fix this. Mixing the older only and except keywords with rules in one pipeline is documented as a source of confusing, split duplicates.

• Open the pipeline file and read the rules of the named job, in order.
• Check whether the main file, not only an include, matches merge request events.
• Count the pipelines created for one push.

Fault two: the job is pending

A runner is chosen only if it carries every tag the job lists. Extra tags on the runner are fine, but a missing one means the job is stuck. A runner set to tagged jobs only will not take an untagged job, and a runner with no tags never takes a job that lists a tag. A runner marked protected takes jobs on protected branches or tags, and can optionally also run jobs in merge request pipelines, so unless it has been set to do that a job on a feature branch can wait a long time while the runner list looks healthy. A runner that is offline takes nothing.

GitLab records why it eventually dropped a pending job: after an hour if no runner matched at all, and after 24 hours if a matching runner existed but never picked it up. The recorded reason on the job tells you which of the two situations you were in.

• Compare the job's tags with each runner's tags, one by one.
• Check whether the runner is online, tagged-only or protected.
• Read the drop reason on a dropped job.

What you can change and what needs an administrator

The pipeline file is yours to change: rules, tags and workflow rules. Runner settings, protected-branch settings and runner registration usually need an owner or administrator of the project, group or instance, and shared instance runners may not be changeable at all. A repair should change the smallest thing: correct a rule or tag, or write the exact runner setting for the administrator to apply. It must never open a protected runner to unprotected branches to make a job start.

How the paid outcome is accepted

The fixed job covers one job or chain in one project. It is accepted when, on a test merge request, the named job appears, is taken by a runner that carries every tag the job lists, and finishes; when exactly one pipeline is created for the event; and when no job was removed or made to ignore failure. Where a runner setting is needed, your administrator applies it and confirms. We never hold runner tokens. It is £175, untested, paid after sign-off. A GitLab job that starts and then fails is not covered by a fixed-price outcome; ask for a quote.