Use GitLab with Evergreen

GitLab appears in the Integrations list twice, and the two entries do different jobs.

GitLab Duo MCP is separate from connecting GitLab as a code host. You can use either one without the other, and a team that wants sessions to open merge requests needs the code host.

GitLab as your code host

Before you begin

• You’re an Owner or Admin of your Evergreen workspace.
• You own a top-level group on your GitLab. Evergreen installs on a group, and the install uses your own GitLab authorization.
• On a self-managed GitLab, you can add an application in its admin area, or a GitLab admin is ready to do it for you.

Install Evergreen on a group

For the scopes and the redirect URI, see Use GitLab instead in Connect your code.

api write_repository

https://gitlab.example.com

Connect your own account

Each person connects their own GitLab account once, Admins included. Go to Settings › Integrations, find GitLab, and choose Connect. A session then acts in GitLab as the person who connected.

Where Evergreen is installed on a group, it also has a bot there. Sessions use the bot in a group wherever a person hasn’t connected their own account.

Manage the installation

Choose Manage on the GitLab entry. The Groups tab lists each group Evergreen is installed on, with its bot or the reason there isn’t one. Choose Install on a group to add another group, Reinstall to repair one, or Remove to take Evergreen off a group. Removing a group revokes the bot’s token and deletes the webhook where GitLab allows it.

Remove on the Overview tab uninstalls Evergreen from all your groups. It disconnects people’s GitLab accounts, and your GitLab address and application are deleted too. If you add GitLab again, setup starts over.

If you change the address to a different GitLab host, people’s GitLab connections are forgotten, because the old application goes with it. They connect again on the new host.

What the agent asks before changing things

Sessions work on a branch and open a merge request for your reviewers. Start in Plan to approve what the agent intends to do before it edits. See Pull requests for what happens after a session opens one.

Limits

• Evergreen installs only on a top-level group that you own.
• On a GitLab plan without group access tokens, Evergreen can’t create a bot. Sessions then act as each person who connected their own account. If the plan has no group webhooks either, each project gets its own webhook the first time a session uses it.
• Evergreen renews the bot’s token before it expires. If GitLab refuses a renewal, the group shows Needs attention and Evergreen tells whoever installed it and the Admins.

GitLab’s own MCP server

GitLab Duo MCP lets the agent read GitLab while it works on a task, for example to read the issue behind a change or the log of a failing job. It’s separate from the code host above. It doesn’t clone, push, or open merge requests.

What the agent can do

• Search projects, issues, merge requests, and code.
• Read issues and merge requests with their discussions and diffs.
• Read pipelines and job logs.
• Create issues and comment on merge requests when you ask.

Changes are attributed to you, and the agent has the permissions of your GitLab account.

Connect it

By default, the integration reaches GitLab.com. For a self-managed GitLab, an Owner or Admin can change MCP server URL in the integration’s settings on the Overview tab of Manage.

What it asks before changing things

While the agent plans, it reads. Creating an issue or commenting on a merge request becomes available once you approve the plan, or from the start if you skip the plan, and the agent is told to do either only when the task asks. Owners and Admins can block any tool for everyone on the Tools tab.

Limits

• It’s GitLab’s beta, so what it offers can change on GitLab’s side.
• It acts only with what your own GitLab account can see and do.

Troubleshooting