Repository Check
The editor can check whether the connected repository is set up the way the publishing workflow expects. You will 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.
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. |
| ⚠️ | The editor could not determine the answer. Usually harmless, but worth a look. |
| ❌ | A real problem: the review workflow can be bypassed. |
| ⊖ | Not checked, because your role is not allowed to read that setting. Expected for editors, and not an error. |
Most fixes are made in GitLab, not in the editor, and most of them need the Chief editor (Maintainer) or Owner role. If a finding is out of your reach, hand this page to whoever administers the repository.
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 CI / CD.
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 — this needs the Chief editor (Maintainer) role.
This is not an error. GitLab only reveals the detailed protection rules to maintainers and owners. Connected as an editor, you see the checks that matter for safety — is the branch protected, are editors kept from pushing and merging — and the two informational points above stay closed to you.
Nothing to do. If you want to see them, you need the Maintainer role — which also means being able to publish.
If the message instead names a technical error, the editor could not reach GitLab. Retry, and check whether your login is still valid.