Which component(s) is affected?
Operator
Describe the bug
GitLab push webhooks are received by Kubero and return a 201 response (visible on GitLab's webhook delivery log), but no rebuild or restart of the app is triggered. The webhook is effectively a no-op.
Steps to reproduce
-
Connect a GitLab repository to a Kubero app
-
Configure a webhook on GitLab for push events (this may be done automatically by Kubero)
-
Push a commit to the branch tracked by the Kubero app
-
Observe on GitLab that the webhook was delivered successfully (201 response)
-
Observe that Kubero does not rebuild or restart the app
Expected behavior
After a push webhook is received from GitLab, Kubero should trigger a rebuild/restart of any apps tracking the affected repository and branch, just as it does for GitHub, Gitea, Gogs, and Bitbucket.
Screenshots
No response
Additional information
Root Cause
There are two bugs, one critical and one secondary.
Bug 1: getWebhook() is never called for GitLab (Critical)
In server/src/repo/repo.service.ts at line 285, the gitlab case in the handleWebhook switch statement extracts the headers but never calls this.gitlabApi.getWebhook() and never assigns its result to the webhook variable:
// server/src/repo/repo.service.ts lines 285-289
case 'gitlab':
event = headers['x-gitlab-event'];
delivery = headers['x-gitlab-event-uuid'];
signature = headers['x-gitlab-token'];
break; // <-- missing: webhook = this.gitlabApi.getWebhook(event, delivery, signature, body);
Every other provider (github, gitea, gogs, bitbucket) correctly calls its getWebhook() method and assigns the result to webhook. Because webhook remains false (its initial value), the guard at line 300 (if (typeof webhook != 'boolean')) fails, and handleWebhookPush() is never reached.
Bug 2: Merge Request Hook uses GitHub payload structure (Secondary)
In server/src/repo/git/gitlab.ts at lines 269-271, the merge request parsing branch incorrectly uses GitHub/Gitea payload field names instead of GitLab's:
// server/src/repo/git/gitlab.ts lines 269-271
} else if (body.pull_request != undefined) { // GitLab has no body.pull_request
(action = body.action), (branch = body.pull_request.head.ref); // body.pull_request is undefined
ssh_url = body.pull_request.head.repo.ssh_url; // body.pull_request is undefined
GitLab Merge Request Hook payloads use body.object_attributes (with fields like source_branch and action), not body.pull_request. This would cause a TypeError reading .head of undefined, caught silently at line 291 and returning false.
Debug information
Affected Versions
Current main branch as of this writing.
Which component(s) is affected?
Operator
Describe the bug
GitLab push webhooks are received by Kubero and return a 201 response (visible on GitLab's webhook delivery log), but no rebuild or restart of the app is triggered. The webhook is effectively a no-op.
Steps to reproduce
Connect a GitLab repository to a Kubero app
Configure a webhook on GitLab for push events (this may be done automatically by Kubero)
Push a commit to the branch tracked by the Kubero app
Observe on GitLab that the webhook was delivered successfully (201 response)
Observe that Kubero does not rebuild or restart the app
Expected behavior
After a push webhook is received from GitLab, Kubero should trigger a rebuild/restart of any apps tracking the affected repository and branch, just as it does for GitHub, Gitea, Gogs, and Bitbucket.
Screenshots
No response
Additional information
Root Cause
There are two bugs, one critical and one secondary.
Bug 1:
getWebhook()is never called for GitLab (Critical)In
server/src/repo/repo.service.tsat line 285, thegitlabcase in thehandleWebhookswitch statement extracts the headers but never callsthis.gitlabApi.getWebhook()and never assigns its result to thewebhookvariable:Every other provider (github, gitea, gogs, bitbucket) correctly calls its
getWebhook()method and assigns the result towebhook. Becausewebhookremainsfalse(its initial value), the guard at line 300 (if (typeof webhook != 'boolean')) fails, andhandleWebhookPush()is never reached.Bug 2: Merge Request Hook uses GitHub payload structure (Secondary)
In
server/src/repo/git/gitlab.tsat lines 269-271, the merge request parsing branch incorrectly uses GitHub/Gitea payload field names instead of GitLab's:GitLab Merge Request Hook payloads use
body.object_attributes(with fields likesource_branchandaction), notbody.pull_request. This would cause aTypeErrorreading.headofundefined, caught silently at line 291 and returningfalse.Debug information
Affected Versions
Current
mainbranch as of this writing.