--- title: "GitLab Integration" description: "Manage GitLab projects, issues, merge requests, repository content, CI/CD pipelines, and releases from your flows over the GitLab REST API v4. Works with GitLab SaaS and self-managed instances." url: https://flowrunner.ai/integrations/gitlab date_modified: 2026-08-01T02:40:32-07:00 --- # GitLab [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Manage GitLab projects, issues, merge requests, repository content, CI/CD pipelines, and releases from your flows over the GitLab REST API v4. Works with GitLab SaaS and self-managed instances. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 27 actions · API key · available [GitLab website](https://gitlab.com/) · [Platform Documentation](https://docs.gitlab.com/ee/api/) · Capability data verified 2026-07-14 1. A monitoring alert or support ticket lands in a flow 2. Agent reads the alert details and maps them to a project and labels 3. Agent lists open issues to avoid filing a duplicate 4. Agent calls Create Issue with the details, labels, and a link back to the source 5. Agent posts the new issue link to the engineering channel 6. An engineer decides whether to open a merge request or triage further before any pipeline runs ## What This Integration Enables FlowRunner agents use GitLab to keep engineering work flowing between systems without a person shuttling data by hand. An agent can turn tickets, form submissions, and monitoring alerts into labeled issues, open and update merge requests, commit generated files or configuration into a branch, and trigger, retry, or cancel CI/CD pipelines. When a release ships, it can publish the release and notify stakeholders. It works against gitlab.com or a self-managed instance without changing the flow. What it does not do on its own is merge to production or fire a production pipeline. Those stay with the engineer who owns the release. ### Without FlowRunner **Manual issue filing**: An engineer copies alert details into GitLab by hand and picks labels each time **Duplicate issues**: The same alert files the same issue twice because nobody checked first **Blind merges**: A release merge happens without a clear record of who approved it ### With FlowRunner **Issues filed on arrival**: The agent files a labeled, linked issue the moment the alert fires **Deduplicated**: The agent checks open issues before filing so the tracker stays clean **Approved merges**: Production merges wait for a named engineer to approve them ## Use Case Scenarios ### Alerts into deduplicated issues A monitoring alert lands in a flow. The agent maps it to the right project, calls List Issues to confirm the same alert has not already filed an issue, and then calls Create Issue with the alert details, the correct labels, and a link back to the source. It adds a note with the first-seen timestamp and posts the issue link to the engineering channel. Engineers open a tracker that is already deduplicated and labeled, instead of a pile of repeats. ### Release tagging after a merge A release workflow reaches the point where a reviewed merge request is ready. After an engineer approves and the agent calls Merge Merge Request, it calls Create Release to tag the version, then emails stakeholders the release notes. The version is tagged and announced without anyone assembling notes by hand. ### Production merge gate A merge request passes CI and is ready to merge into the default branch. The agent does not merge it. It posts the merge request, its pipeline status, and its diff summary to the release channel and asks the reviewing engineer to approve. Only after the engineer approves does the agent call Merge Merge Request. Code reaches production behind a decision a person made and a record shows they made it. ## Human-in-Loop Highlight The human-in-loop moment in GitLab is the production merge and pipeline gate. Reading issues, filing them, committing to a feature branch, and running CI on a branch are all reversible or low-stakes, so the agent runs them by rule. Merging into the default branch and triggering a production pipeline are not, so the agent stops. When a merge request is green and ready, the agent posts it to the release channel with its pipeline status and asks: "MR !482 is green and ready to merge into main. Approve the production merge?" A named engineer approves. Only then does the agent call Merge Merge Request, and, where the flow ships from a pipeline, Trigger Pipeline. The agent keeps the tracker and the branches moving. A person owns the moment the change goes live. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 27 actions ### Projects 2 - **List Projects** List the projects the authenticated token can access. Used to resolve a project before other actions. - **Get Project** Retrieve a single project by numeric ID or namespaced path. ### Issues 5 - **Create Issue** File a new issue in a project. Used to turn a support ticket or monitoring alert into a tracked bug. - **Get Issue** Retrieve a single issue by its project-scoped internal ID. - **List Issues** List the issues in a project. Used to check for duplicates before filing. - **Update Issue** Change an issue's state, labels, assignees, or fields. - **Create Issue Note** Add a note (comment) to an issue. ### Merge Requests 6 - **Create Merge Request** Open a merge request from a source branch into a target branch. - **Get Merge Request** Retrieve a single merge request by its internal ID. - **List Merge Requests** List the merge requests in a project. - **Update Merge Request** Update a merge request's title, description, labels, or reviewers. - **Merge Merge Request** Merge a merge request into its target branch. Run it behind a human approval on production merges. - **Add Merge Request Note** Add a note (comment) to a merge request. Used to post automated review notes. ### Repository 7 - **List Branches** List the branches in a project repository. - **Create Branch** Create a branch from a ref. - **Delete Branch** Delete a branch. - **Get File** Read a file's contents at a path and ref. - **Create or Update File** Commit a new or changed file to a branch. - **List Commits** List the commits on a branch or across the repository. - **Create Commit** Create a commit with one or more file actions in a single request. ### Pipelines 5 - **List Pipelines** List the CI/CD pipelines for a project. - **Get Pipeline** Retrieve a single pipeline and its status. - **Trigger Pipeline** Start a pipeline on a branch or tag. Run it behind a human gate when it targets production. - **Retry Pipeline** Retry the failed jobs in a pipeline. - **Cancel Pipeline** Cancel a running pipeline. ### Releases 2 - **List Releases** List the releases for a project. - **Create Release** Publish a release tied to a tag. Used to ship a version and notify stakeholders. ## Frequently Asked Questions ### What can FlowRunner do with GitLab? FlowRunner agents can run List Projects, Get Project, and Create Issue in GitLab, plus 24 more actions. ### Does connecting GitLab to FlowRunner require OAuth? No. GitLab connects to FlowRunner with an API key, no OAuth flow required. ### Can GitLab trigger a FlowRunner workflow automatically? GitLab doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at GitLab?** This integration exposes GitLab to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/gitlab. Site index: https://flowrunner.ai/llms.txt