TestingOps.ai

Issue trackers, wikis and code · Native connection

GitLab and TestingOps: AI test agents on issues and board lists

TestingOps reads a GitLab project's issues, merge requests and README into its knowledge base, follows the lists of your issue board with the Tester Agent and reports defects back as GitLab issues, on gitlab.com or your own GitLab server.

  • Native connection
  • Available
Request a demo GitLab Docs: personal access tokens
Connection
Native connection
Writes back
Within what you allow
Last checked
7 Nov 2026

In short

GitLab and TestingOps in short

The GitLab connection links one GitLab project, on gitlab.com or a self-managed server, to a TestingOps project. Its issues, merge requests and README become context that agents search when they write and review test cases.

The Tester Agent receives issue and comment events from a project webhook and treats the lists of your issue board as columns, so moving an issue to your test list can start refinement, case writing or a run, with the outcome posted as a note.

You connect with a private token, or with Connect with GitLab on gitlab.com. If issues or merge requests are switched off in the project, that part is skipped and the rest still syncs.

What it does

What it does for your testing

  1. 1

    Issues and merge requests become test context

    Input
    Issues and merge requests with title, description, state and last update, plus the README
    TestingOps
    Keeps up to 300 per sync as requirements in the project's knowledge base, issues first
    Output
    Context for writing and reviewing cases, with links back to GitLab
  2. 2

    A board list becomes an agent step

    Input
    An issue moved to a list of your issue board
    TestingOps
    Runs what your board rule gives that list: refine, propose acceptance criteria, write draft cases or run the linked cases
    Output
    Notes on the issue and, after approval, sections added to its description
  3. 3

    Jira keys in GitLab commits feed impact analysis

    Input
    Commits and branches whose message or name carries a Jira key
    TestingOps
    The Jira Tester Agent collects the files they changed in the last 90 days
    Output
    Changed files the agent uses when it selects the cases to run
  4. 4

    A defect becomes a GitLab issue

    Input
    A TestingOps defect
    TestingOps
    Opens an issue in the linked project with the label bug
    Output
    The issue key and link stored on the defect

Step by step

How it works

  1. Connect GitLabUnder Integrations → Project tools, open GitLab and enter a private token; for a self-managed server, enter its address as the base URL. On gitlab.com you can use Connect with GitLab instead.
  2. Link a projectIn Knowledge Base, add the GitLab project (group/project) as a Code source. Each sync reads up to 300 issues and merge requests and the README, hourly and on Sync now.
  3. Agents work with itAgents search the records with the project's other knowledge, and list folders, open files and search code in the project through the GitLab API when a task needs it.
  4. Connect the Tester Agent (optional)Generate a webhook address on the connection and add it in GitLab under Settings → Webhooks with Issues events and Comments. The board rule wizard reads the lists of the project's first issue board.
  5. Write backWith the link's write switch on, the agent posts Markdown notes, changes labels and closes or reopens issues; reported defects become issues labelled bug.

On a GitLab issue board each list is a label. The wizard puts opened first and closed last; moving an issue between lists is a label change that the agent reads as a transition.

Connect

Setup

  1. In TestingOps, open Integrations → Project tools, select GitLab and enter a private token; for a self-managed server, enter its address as Base URL. On gitlab.com you can choose Connect with GitLab instead.
  2. If the server is only reachable inside your network, pick its gateway under Connect through a private network, then select Test connection and Connect.
  3. In Knowledge Base, pick the project, select + Add source under Code, choose the connection, pick the GitLab project and select Link to RAG.
  4. Turn on Agents may write to this tracker on the source if agents should post notes or change issues.
  5. Optional: on the connection select Generate webhook address, add it in GitLab under Settings → Webhooks with Issues events and Comments, then open Board rules.

Documentation: GitLab Docs: personal access tokens · GitLab Docs: webhooks

Where you connect it in TestingOps: Integrations → Project tools → Issue trackers, wikis and code → GitLab

Use cases

Use cases

Prepare test cases while an issue is in development

Trigger
An issue reaches your test-design list
Uses
The issue description and nearby knowledge-base entries
Agent activity
Proposes acceptance criteria and open questions, then writes draft cases once a person approves with /testingops approve
Result
A note with the proposal, then draft cases linked to the issue
Condition
Notes on merge requests are not events for the agent

Use the Jira key convention on a self-managed GitLab

Trigger
A Jira item moves to Test while its code lives in GitLab
Uses
Commits and branches in the linked GitLab project that carry the Jira key
Agent activity
The Jira Tester Agent adds the changed files to its impact analysis, runs the selected cases and comments on the Jira item
Result
A Jira comment with the run result and a link to the run
Condition
The team writes the Jira key in commit messages or branch names

Reach a GitLab server inside your network

Trigger
GitLab is only reachable over the company VPN
Uses
A private network gateway chosen on the connection
Agent activity
Syncs, file reads and agent writes go through the gateway
Result
Issues, merge requests and files available as on gitlab.com
Condition
A private network must be set up under Integrations → Private networks (VPN)

Run the plan after a GitLab deployment

Trigger
GitLab sends a deployment event with status success for your environment
Uses
A Run on deploy trigger on a TestingOps test plan
Agent activity
Starts the plan's run; a GitLab CI job can wait for the gate's verdict
Result
A run on RunningOps and a pass or fail verdict for the pipeline
Condition
Only a successful deployment to the named environment starts a run

Capabilities

Capabilities and limits

What is read

  • Issues and merge requests of the linked project: title, description, state and last update; up to 300 per sync, issues first
  • The README, as a know-how document
  • On demand for agents: an issue with its notes, issue search in the project, folders, files up to 200 KB and code search through the GitLab API
  • For the Jira Tester Agent: commits and branches that carry a Jira key, and the files they changed (last 90 days)
  • Tester Agent events: issues opened, closed, reopened or relabelled, and notes on issues

What is produced

  • Requirements and a README document in the project's knowledge base
  • Refinement proposals, acceptance criteria and draft cases linked to an issue
  • Test plan runs started by GitLab deployment events

Where it can write

  • Issues labelled bug through Report to… on a defect
  • With "Agents may write to this tracker": notes, close or reopen, new issues, and title, label, assignee or description changes
  • Tester Agent: Markdown notes, approved description sections and list labels
  • Not written: code, branches, merge request approvals or pipeline status

How it connects

  • A private token, for gitlab.com and self-managed GitLab
  • Connect with GitLab (scopes api and read_user), for gitlab.com only
  • Optional: a private network gateway for a server inside your network
  • Tester Agent: a project webhook; Run on deploy: a project webhook for Deployment events or a CI job

Account and permissions

  • TestingOps reads and writes with the permissions of the token or the signed-in GitLab user
  • Agent writes need the link's "Agents may write to this tracker" switch
  • A project maintainer adds the webhooks

Limits

  • 300 issues and merge requests per sync; notes and attachments are not stored
  • Merge request events and merge request notes do not start agent rules
  • The board rule wizard reads the project's first issue board
  • When a project links several repositories, agents open files in the first one
  • Connect with GitLab works on gitlab.com only; self-managed servers use a token

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A team runs GitLab on its own server behind the company VPN and plans in Jira. The GitLab connection goes through a private network gateway, and developers name branches after Jira keys, such as feature/PAY-88-refunds.

When PAY-88 reaches Test in Jira, the Tester Agent finds that branch in the linked GitLab project, adds its changed files to the impact analysis, runs the selected cases on RunningOps and comments the result on the Jira item.

Frequently asked questions

Does it work with self-managed GitLab?

Yes. Enter your server's address as the base URL and use a private token; Connect with GitLab is for gitlab.com. A server that is only reachable inside your network can be reached through a private network gateway.

What if issues are switched off in my GitLab project?

That part is skipped and the sync goes on with merge requests and the README. The same applies when the token cannot see one of the parts.

Can the agent react to merge requests?

No. The Tester Agent follows issues and notes on issues. Merge requests are read into the knowledge base as context, but their events do not start agent rules.

How do issue board lists map to agent rules?

Each list of an issue board is a label. The wizard reads the lists of the project's first board, with opened first and closed last, and you write one sentence per list. When the agent moves an issue, it swaps the list label.

Does a push to GitLab start a test run?

No. Runs start from a test plan's Run on deploy trigger when GitLab reports a successful deployment, from a CI job, or from the Tester Agent when an issue reaches your test list.

Which token permissions are needed?

Reading the project is enough for syncing and file reads. Notes, label changes, closing issues and defect filing need a token whose scopes allow writing issues.

Next step

Bring a GitLab project and its issue board to a demo and see the agent follow your lists.

Request a demoMore project tools integrations