Conversation
|
Changing this to draft while waiting for GitLab to implement signed webhooks, which seems like might happen soon: https://gitlab.com/gitlab-org/gitlab/-/work_items/19367 Based on the issue description, the signature will be "an HMAC-SHA256 hex digest of |
The signature verification now matches planned implementation: https://gitlab.com/gitlab-org/gitlab/-/work_items/19367
|
This PR should now (hopefully) support the upcoming GitLab implementation. Meanwhile, I have created a Smee server fork for testing here that signs GL webhooks using the "secret" token. To test the PR, one can use the Smee server fork and a Smee client, and create a webhook on some GL project with the from pyghee.lib import PyGHee, create_app, GITLAB
from pyghee.utils import log
import waitress
class GLTest(PyGHee):
def __init__(self):
super().__init__(event_source=GITLAB)
def handle_note_event(self, event_info, log_file=None):
comment_body = event_info["raw_request_body"]["object_attributes"]["note"]
log(f"Comment received: {comment_body}", log_file=log_file)
if __name__ == "__main__":
app = create_app(GLTest)
print("Starting GitLab test app, listening on port 3000")
waitress.serve(app, listen="*:3000") |
Implements support for handling GitLab events.
The
PyGHeeclass is configurable for GH vs. GL using theevent_sourceparameter, which defaults to'github'.When it is configured to handle GitHub events it should function as before, meaning that this PR (hopefully) does not contain any breaking changes.
This implementation assumes that some intermediary, e.g. a custom Smee server, uses the webhook secret to sign the event and add an
X-Gitlab-Signatureheader since GitLab does not yet support webhook signatures.I'm open to making both major and minor changes if you have any suggestions. I personally think the if/elif/elses look a bit messy, especially in the constructor.