GitLab connects using a personal access token. Configure it at Settings → Connections → Source control.
Creating the token
In GitLab, create a personal access token with the api scope. That covers
reading repository contents, creating branches, and opening merge requests.
Paste it into the source control settings. Coroid encrypts it at rest, never returns it through the interface or API, and never includes it in settings exports.
Token ownership
For shared team use, create the token on an account intended for automation rather than an individual's, so the connection survives people changing roles.
Set an expiry you will actually track. A token that expires without anyone noticing presents as work suddenly failing to push, which is a confusing symptom to diagnose from the failure message alone.
Merge requests
Coroid opens merge requests the same way it opens pull requests on GitHub — branch per task, pushed when the work is ready, targeted at your base branch.
Coroid never merges on its own. A merge happens only when a person merges the merge request in GitLab or presses Approve & merge in Coroid.
Your existing approval rules and pipeline requirements apply unchanged. Approve & merge merges through the merge request too, so the same rules decide whether it succeeds. See Merging.
GitLab Review Apps
Where you use GitLab Review Apps, those environments can be attached to merge requests as review evidence. See Review evidence.
Self-managed GitLab
Connection assumes your GitLab instance is reachable from Coroid. For a self-managed instance behind a network boundary, that is a prerequisite to sort out before the token matters.