Skip to content

[gitlab] Add GitLab connection and EventInfo classes#370

Open
sondrebr wants to merge 9 commits intoEESSI:gitlabfrom
sondrebr:add-gitlab-support-event-info-classes
Open

[gitlab] Add GitLab connection and EventInfo classes#370
sondrebr wants to merge 9 commits intoEESSI:gitlabfrom
sondrebr:add-gitlab-support-event-info-classes

Conversation

@sondrebr
Copy link
Copy Markdown
Collaborator

First step towards implementing GitLab support for the bot. This PR adds:

  • New/updated dependencies (python-gitlab, PyGHee with GitLab support)
  • New config sections git and gitlab
  • connections/gitlab.py for connecting to GitLab
  • tools/git.py with functions:
    • get_hosting_platform() gets the configured Git hosting platform (GitHub/GitLab)
    • connect_to_host() performs initial connection to GitHub/GitLab
  • tools/event_info.py with:
    • BaseEventInfo class intended as an "interface" to implement for each Git hosting platform
    • GitHubEventInfo class implementing BaseEventInfo for GitHub
    • GitLabEventInfo class implementing BaseEventInfo for GitLab
    • create_event_info_instance() creating an instance of the correct EventInfo class
  • A handle_event() override in the event handler to use the new EventInfo classes

The PR does not any methods for handling GitLab events, but the events will be logged, e.g.:

[20260421-T10:53:03] Event received (id: 39c64e78-fdd1-4799-a9c6-568d9b7ffb4b, type: note, action: create), event data logged at [...]
[20260421-T10:53:03] Request verified: signature OK!
[20260421-T10:53:03] WARNING: [event id 39c64e78-fdd1-4799-a9c6-568d9b7ffb4b] No handler found for event type 'note' (action: create) - event was received but left unhandled!

get_hosting_platform() is intended to be used whenever platform-specific logic is required, to simplify adding support for other platforms in the future (e.g. Forgejo/Codeberg, Gitea, ...).

The *EventInfo classes were implemented to handle the differences between the GitHub and GitLab webhooks, such that the necessary information can be retrieved through class properties. For example, event_info.action returns the event action. If GitLabEventInfo is used, the action property converts the action to its GH equivalent before returning, e.g. update becomes edited.
The classes currently have support for (as far as I can tell) all event_info fields used by the bot.
They also have a __getitem__() override to support subscripting for compatibility with the existing uses of event_info - this version of the bot should therefore still have full GitHub support.

Usage

Because webhooks signatures are not yet supported by GitLab (though they are in development), it is necessary to run a custom Smee server to sign the webhooks. I have a fork here which should sign the events in the same way as they will be signed on GitLab in the future. I have also added a "Quickstart" section on top of the README in the fork with instructions on how to run the server.

To "use" the bot in its current state on GitLab, you need to do the following:

  • Install the requirements (pip install -r requirements.txt)
    Ensure the correct version of PyGHee (commit c5e1063...) is installed.
  • Create a webhook on a GitLab project (Settings -> Webhooks -> Add new)
    The webhook should have the Comments and Merge request events triggers, and must be configured with a secret token. The secret token can be generated e.g. by running python -c "import secrets; print(secrets.token_hex())", and must be stored as the environment variable GITLAB_WEBHOOK_SECRET_TOKEN. The webhooks must also be set up to send events to the custom Smee server.
  • Create a project access token for the same GitLab project (Settings -> Access tokens -> Add new token)
    In the future, the api scope and Planner will be required for the bot to be able to write comments. For this PR, however, it just needs to be able to connect to GitLab, so the read_api scope and Guest role should be sufficient. The access token must be stored as the environment variable GITLAB_PROJECT_ACCESS_TOKEN.
  • Configure the git and gitlab sections in app.cfg
    In the git section, hosting_platform = gitlab must be set (if it is set to github instead, the bot should function normally).
    In the gitlab section, the api_timeout, bot_name, and instance_url options must be set. For the instance_url option, you must enter the base URL of your GitLab instance, which is used along with the access token to connect to GitLab.

@sondrebr sondrebr changed the base branch from gitlab to develop April 23, 2026 11:51
@sondrebr sondrebr changed the base branch from develop to gitlab April 23, 2026 11:51
@sondrebr
Copy link
Copy Markdown
Collaborator Author

Had to temporarily switch the base branch to get rid of some old commits 🤦 Ready for review now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant