Repository Check
The editor can check whether the connected repository is set up the way the publishing workflow expects. Users with the Maintainer role or above find it as the expandable Check repository setup section in the branch and merge-request dialog: press Run check and the editor reports one line per finding. Everyone else does not see the section, since only a Maintainer can change what it inspects.
Every finding links here. This page explains, for each of them, what the editor looked at, why it matters, and what to change.
Reading the result
| Icon | Meaning |
|---|---|
| ✅ | Everything is as it should be — nothing to do. |
| ⚠️ | Either a setting is looser than the publishing workflow expects, or the editor could not determine it. Worth a look, but nothing is broken. |
| ❌ | A real problem: the review workflow can be bypassed. |
| ⊖ | Not checked, because the editor could not read that setting. The finding's section says why that can happen. |
Fixes are made in GitLab, not in the editor, and need the Maintainer or Owner role — the role the check is shown to.
Branch protection
These findings all concern the published branch — the branch your site is built from, usually main. The reference setup they check against is described in Roles & Review Workflow.
The published branch could not be read
What the editor reports: Could not read "main": …
Why it matters: Without reading the branch, the editor cannot judge any of the other points, so the remaining checks are skipped. It usually means the branch does not exist under that name, or your account cannot see it.
How to fix it:
- Open the repository in GitLab and check under Repository → Branches whether the published branch exists.
- If it exists under a different name, make that branch the project's default branch (Settings → Repository → Branch defaults) — the editor publishes into the default branch.
- If the branch is there but the editor still cannot read it, your account is probably missing access to the project. Ask for at least the Developer role.
A brand-new, still empty repository has no branch at all. That is not a misconfiguration — set the repository up first, see Starting a new website.
The published branch is not protected
What the editor reports: "main" is not protected — the review workflow can be bypassed entirely.
Why it matters: Branch protection is what separates proposing from publishing. Without it, everyone with write access can publish directly to the live site, and the four-eyes principle exists only by convention.
How to fix it (needs Maintainer or Owner):
Go to Settings → Repository → Protected branches.
Protect the published branch with these rules:
Setting Value Allowed to merge Maintainers Allowed to push No one Run the check again in the editor.
Editors can push directly
What the editor reports: Editors can push directly, bypassing review.
Why it matters: A direct push to the published branch changes the live site without a merge request. Nobody reviews it, and nothing records that a decision was made.
How to fix it (needs Maintainer or Owner): under Settings → Repository → Protected branches, set Allowed to push for the published branch to No one. Chief editors do not need push rights — they publish by merging.
If the editor instead reports Could not determine the push rule, your GitLab edition does not expose that flag to your role. Verify the setting manually using the table above.
Editors can publish without review
What the editor reports: Editors can publish unreviewed — there is no chief-editor gate.
Why it matters: Merging into the published branch is publishing. If editors may merge, then every editor is effectively a chief editor and their own reviewer.
How to fix it (needs Maintainer or Owner): under Settings → Repository → Protected branches, set Allowed to merge for the published branch to Maintainers, and give chief editors the Maintainer role (Manage → Members).
If you deliberately want a smaller team without a review gate, this finding can stay — but then everyone involved should hold the Maintainer role, so that nobody is shown a publish button that fails.
Who may publish
What the editor reports: Publishing is allowed for: …
This is information, not a problem — the exact list of roles, users, or groups GitLab lets merge into the published branch. Expect Maintainers here. If the list says no one, nobody can publish at all and merge requests will pile up unmerged; if it names roles below Maintainer, the review gate is wider than the recommended setup.
Adjust under Settings → Repository → Protected branches → Allowed to merge.
Who may push
What the editor reports: Direct push is allowed for: …
Also information. In the recommended setup this reads no one: everything reaches the published branch through a merge request. Anyone listed here can change the live site without review.
Adjust under Settings → Repository → Protected branches → Allowed to push.
The exact protection rules were not checked
What the editor reports: Not checked — GitLab refuses access to the protection rules.
GitLab reveals the detailed protection rules only to maintainers and owners. The check is shown to them alone, so a refusal means your role in the project changed after you connected. Connect again; the editor then works out your role afresh.
If the message instead names a technical error, the editor could not reach GitLab. Retry, and check whether your login is still valid.
Does the build's verdict count
Branch protection says who may publish. These two say whether what the build found has any force — and they matter as soon as your pipeline reports something a reader is meant to act on, such as a link pointing at a page that is not there.
Both are warnings, never failures. A site that is not live yet has good reason to publish regardless of what a build says; the point of the finding is that you should know which of the two situations you are in.
A merge does not wait for its pipeline
What the editor reports: A merge request can be merged although its pipeline failed — what the build reports is optional reading.
Why it matters: A merge request is where a content mistake is still cheap to fix. If a red pipeline does not stand in the way, that moment passes unused: the change is published and the finding stays in a job log nobody opens.
How to fix it (needs Maintainer or Owner): under Settings → Merge requests → Merge checks, tick Pipelines must succeed.
Leave it off deliberately while a site is being built and nothing is live yet — but then the pipeline is a hint, not a gate, and a broken link reaches the published branch as easily as a correct one.
Merge requests are built against their own branch
What the editor reports: A merge request is only built against its own branch, so two changes can each pass and still break each other once both are published.
Why it matters: This is the one fault no check inside a single merge request can see. Your draft renames a page; a colleague's draft, written at the same time, links to the old name. Both pipelines are green, because neither was ever built together with the other. The published branch is the first place the two meet.
How to fix it (needs Maintainer or Owner, and GitLab Premium or above): under Settings → Merge requests → Merge options, enable Merged results pipelines. GitLab then builds the merge request as the published branch will look after the merge.
If the editor reports this GitLab does not offer merged results pipelines, the feature is not part of your edition and there is nothing to switch on. The pipeline on the published branch is then the place where such a pair is caught — which is one reason a finding there is reported rather than allowed to stop the deployment.