> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt
> Use this file to discover all available pages before exploring further.

# GitLab API

> Read and commit repository files, review merge requests, and work issues and pipelines in GitLab from an agent

> [!NOTE]
>
> Automatically enabled when you configure GitLab permissions in your agent workflow.

## What it does

* Read repository files, the file tree, commits, branches and tags, and compare two branches
* Commit several file changes to a branch in one commit, and create and delete branches and tags
* Open, read, comment on, approve and merge merge requests
* Create, comment on and close issues, and read labels, milestones, boards and epics
* Read pipelines, jobs and job logs, and run, retry or cancel them
* Read and change wikis, snippets, releases, packages and project settings, as the permission groups allow. Safety Controls below lists what always asks

Neo acts as the access token you saved: it sees and changes only what that token's role allows, and GitLab itself refuses the rest. Use a project access token to keep every agent's writes in one repository. Neo hides runner, trigger and webhook tokens, application secrets, support PINs and CI/CD variable values in every answer; a repository file is returned as it is. A hidden field reads `[hidden by Neo]`, and Neo refuses a write that sends it back, so a secret is never overwritten with the mark.

## Choose where each agent works

Name the project and branch in the agent's instructions, for example "Commit into the folder *neo-agents* on *main* in the project *my-group/neo-agents*". To keep every agent out of a project, connect GitLab with a project or group access token that cannot reach it.

## Permission groups

| Group | Covers |
| - | - |
| Repository | Files, the tree, commits, compares, branches, tags and blame; search, whose scopes include code; project exports; committing, cherry-picking and reverting |
| Merge Requests | Merge requests, their changes, comments, discussions and approvals, merge trains and approval rules |
| Issues & Planning | Issues, labels, milestones, boards, iterations, epics and to-dos |
| CI/CD & Deployments | Pipelines, jobs and their logs, schedules, environments, deployments, runners, feature flags, error tracking and CI/CD variables (values hidden) |
| Packages & Registries | Packages, the container registry and its tags |
| Wikis, Snippets & Releases | Project and group wikis, snippets, releases and uploads |
| Projects & Groups | Projects and groups with their settings, webhooks, integrations, protected branches and deploy keys |
| Members & Access | Members, invitations, access requests, sharing, users, SSH keys, and the list of access tokens with their revocation |
| Security & Compliance | Vulnerabilities, security scans, dependency lists and audit events |
| Instance Administration | Settings of a self-managed GitLab server; needs an administrator's token |

Each group can be Disabled, Read Only or Read / Write, with or without a technician's approval for changes.

| Profile | What it does |
| - | - |
| Read Only | Reads every group, changes nothing |
| Helpdesk | Commits, merge requests and issues ask a technician first; the other groups read only |
| IT Admin | Commits, reviews, and works issues, pipelines, wikis and packages on its own; project settings, access, security and the server ask a technician first |
| Full Automation | Every change with no approval, except those Safety Controls lists |

## Safety Controls

These always ask a technician, whatever the profile:

* Every Members & Access change except one that only takes access away (removing a member, blocking, banning or deactivating a user), and deleting a user
* A deploy key, a runner assigned or changed, the CI job-token allowlist, a fork, and a transfer to another namespace (a project moved into a group included), which give access to your code
* Protected branches, tags and environments, push rules, merge request approval rules and settings, and a pull mirror, which decide what protects your code, and a gate's action: protecting or unprotecting a branch, a status check's response, a commit status, approving a deployment
* Kubernetes clusters and cluster agents, which decide where deployments go, and freeze periods and resource groups, which keep them safe
* Cloning or moving an issue to another project
* Package, container registry and Terraform state protection rules, and virtual registries and their upstreams
* Every change to a self-managed server's own configuration (Instance Administration), such as Sidekiq queues, instance CI variables, applications, licenses and Geo sites
* Security settings, such as secret push protection, and security policies, and the server's application settings, such as required two-factor sign-in
* A push mirror, a webhook, an integration, an external status check, an export, an offline export and an import (a remote import can replace a project), which move your code or its events in or out of GitLab
* A project or group update that widens who sees it (its visibility, public jobs, a feature's access level) changes where its code comes from (pull-mirror settings, the import URL, the CI configuration path), turns off a merge gate (a required pipeline, resolved discussions, status checks, approvals), or loosens who may sign in, join, share, fork or push (required two-factor sign-in, IP restrictions, allowed email domains, sharing and membership locks, default branch protection)
* Archiving, unarchiving or restoring a project or a group, and deleting one

Every other change, such as a project's description or badges, follows its group's own approval setting.

Neo never sends these:

* Creating or rotating an access, deploy or runner token, or an application secret, because the answer is the new credential
* Terraform state and secure file downloads, which hold secrets in plain text
* The package-manager protocols (npm, Maven, PyPI and the rest), and file uploads
* The endpoints only a runner, a CI job token or a pipeline trigger token can call
* GitLab's query language (GLQL), GitLab Duo's AI endpoints, Markdown rendering, cross-resource counters, the activity feeds (events), the to-do list, export downloads, release evidence and Markdown uploads, which read issues, merge requests and code in one call, past the agent's permission groups
* `sudo`, which would run a call as another GitLab user
* The Search API with a scope other than code (`blobs`, `commits`); each list's own `search` filter covers the rest, under its own permission group

## Setup

See [Connecting GitLab to Neo](https://docs.neoagent.io/integrations/gitlab/connecting-to-neo.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.