Implementation:OpenHands OpenHands GitlabManager

Knowledge Sources	OpenHands
Domains	Platform_Integration, GitLab_API
Last Updated	2026-02-11 21:00 GMT

Overview

Concrete tool for orchestrating the full GitLab webhook lifecycle including event qualification, message processing, and job dispatch, provided by the OpenHands enterprise integration layer.

Description

The GitlabManager class extends the base Manager class to implement GitLab-specific webhook handling and resolver job orchestration. It serves as the central coordination point for all GitLab integration activity, translating incoming webhook payloads into internal conversation and job representations.

The is_job_requested method evaluates an incoming webhook event to determine whether it qualifies for automated processing. It inspects the event type (merge request comment, issue comment, etc.) and verifies that the triggering content matches the bot invocation pattern.

The receive_message method is the primary entry point for webhook processing. It parses the incoming GitLab webhook payload, extracts repository and user context, determines whether the event warrants action via is_job_requested, and if so, delegates to the appropriate view factory for conversation creation and job dispatch.

The send_message method handles outbound communication back to GitLab, posting comments on merge requests or issues to report resolver progress and results.

The start_job method initiates the actual resolver job execution after all preconditions (event qualification, permission checks, view creation) have been satisfied.

The _user_has_write_access_to_repo helper method authenticates via the GitLab API and verifies that the user who triggered the webhook event has at least Developer (write-equivalent) access to the target repository, implementing a fail-closed security posture where any API error results in access denial.

Usage

Use GitlabManager as the handler for GitLab webhook endpoints. The server routes incoming GitLab webhook POST requests to receive_message, which manages the full lifecycle from event validation through job creation. Configure with appropriate GitLab credentials and token management during server initialization.

Code Reference

Source Location

• Repository: OpenHands
• File: enterprise/integrations/gitlab/gitlab_manager.py
• Lines: 1-273

Signature

class GitlabManager(Manager):
    async def is_job_requested(self, message: Message) -> bool:
        ...

    async def receive_message(self, message: Message) -> None:
        ...

    async def send_message(
        self,
        conversation_id: str,
        content: str,
    ) -> None:
        ...

    async def start_job(self, job_context: dict) -> None:
        ...

    def _user_has_write_access_to_repo(
        self,
        installation_id: str,
        full_repo_name: str,
        username: str,
    ) -> bool:
        ...

Import

from enterprise.integrations.gitlab.gitlab_manager import GitlabManager

I/O Contract

Inputs

Name	Type	Required	Description
message	Message	Yes	Pydantic model containing the GitLab webhook payload with source type, message body, and ephemeral flag
conversation_id	str	Yes	Identifier of the conversation to post a message to (for send_message)
content	str	Yes	The text content to post as a comment on the GitLab merge request or issue (for send_message)
job_context	dict	Yes	Context dictionary containing all parameters needed to start the resolver job (for start_job)
installation_id	str	Yes	The GitLab integration or group ID for API authentication (for _user_has_write_access_to_repo)
full_repo_name	str	Yes	The full repository path in namespace/project format (for _user_has_write_access_to_repo)
username	str	Yes	The GitLab username of the event sender (for _user_has_write_access_to_repo)

Outputs

Name	Type	Description
is_requested	bool	True if the event qualifies for job creation and the user has write access; False otherwise (from is_job_requested)
has_access	bool	True if the user has Developer-level or higher access to the repository (from _user_has_write_access_to_repo)

Usage Examples

from enterprise.integrations.gitlab.gitlab_manager import GitlabManager
from enterprise.integrations.models import Message, SourceType

# Initialize the GitLab manager
manager = GitlabManager(
    token_manager=token_manager,
    data_collector=data_collector,
)

# Process an incoming GitLab webhook
message = Message(
    source=SourceType.GITLAB,
    message=webhook_payload_dict,
    ephemeral=False,
)

# Full lifecycle: check qualification then process
if await manager.is_job_requested(message):
    await manager.receive_message(message)

# Send a response back to GitLab
await manager.send_message(
    conversation_id="conv-789",
    content="Resolver has completed. See the merge request for results.",
)

Related Pages

Environment

• Environment:OpenHands_OpenHands_Integration_Credentials