Jenkins Git plugin webhook support

[fhuberts]

Feature Description

Please add a webhook that supports the Jenkins Git plugin. This plugin exposes a Jenkins URL that will scan all jobs to see if they need building, based on the clone URL that is handed to it. A simple GET request on that URL is sufficient. The format of that URL is <jenkins-url>/git/notifyCommit?url=<clone-url>.

So the only thing needed in the Gitea webhook to be configurable is the Jenkins URL and the clone URL to use.

I've followed the webhooks guide to implement this in php, but having this natively in Gitea would be much much better. And since it's quite a simple interface, it shouldn't be very hard to do.

My implementation can be found here:

• Code: https://gitlab.com/fhuberts/rpmsUpstream/-/blob/master/fedora/gitea/usr/share/gitea/webhooks/jenkins-git-plugin.php
• Docs: https://gitlab.com/fhuberts/rpmsUpstream/-/blob/master/fedora/gitea/usr/share/doc/gitea/webhooks/jenkins-git-plugin

Screenshots

No response

[fhuberts]

It would be nice if this was added to the current stable release.

[beyerjsb]

I wanted/needed this myself, but after some pondering, I realized that my knowledge about how post-receive-hooks in Git work, blinded me about the ways Gitea does work. You don't have to provide a generic webhook script in Gitea. You have to manually configure the webhook for each git repo. Thus, you can simply craft that webhook URL.

Go to your repo's Admin page, Webhooks section, create a new webhook of type Gitea, and configure it:

Target URL: https://yourjenkinsserver/jenkins/git/notifyCommit?url=https://yourgiteaserver/yourgitearepo.git Method: GET Trigger: Push

Save it, test it. For me it works. And since you have to configure it for each repo anyway, it's a bit overhead, but absolutely in the way how Gitea works regards of repos.

[fhuberts]

I know, and I did it like that until it started to fail... The problem is that you have to choose the type of the webhook, and that determines the payload that is sent to the webhook URL. I chose 'Gitea' as type and that sends quite a large json object to the webhook. So large in fact that my Jenkins started choking on it.

Hence my solution.

[beyerjsb]

How about Gitea provides just a toggle (yes/no) for the Gitea Webhook if the payload should be sent or not. Very simple, quick change. Would help in this case.

[fhuberts]

That would work as well for this use-case. (I'm still keeping my code in place for more complex use-cases though ;-) )

[lunny]

How about use https://github.com/jenkinsci/gitea-plugin directly?

[fhuberts]

However, 1 small advantage of my solution is that the webhook is the same for every repo. But that is just my personal preference.

[fhuberts]

How about use https://github.com/jenkinsci/gitea-plugin directly?

I have no need for that currently.

[beyerjsb]

How about use https://github.com/jenkinsci/gitea-plugin directly?

This is not the same.

Using the API the Jenkins Git plugin provides, it triggers the polling of the repos, and takes polling options into account, and subsequently only triggers builds which are required. No additional security/account handling required. Using the Jenkins Gitea plugin, it needs a Jenkins account, and then triggers a build directly, unconditionally.

[weberhofer]

As suggested above, it would be great, if a GET request could be implemented, to trigger a rebuild in Jenkins. I have tested a lot integration gitea and jenkins.

The most simple method to trigger a rebuild in jenkins would be a GET web-hook following this schema: https://JENKINS-HOST/job/MY-PROJECT/build?token=MY-TOKEN

The only web-hook integrated is the "Gitea" hook. It allows sending the hook as GET request. unfortunately this results in the following response from jenkins:

<h1>Bad Message 431</h1><pre>reason: Request Header Fields Too Large</pre>

I think it would be good to have an separate option for the gitea web-hook GET without body or an additional web-hook provider for jenkins which both are simply sending GET requests without body.

[ArslanTu]

As suggested above, it would be great, if a GET request could be implemented, to trigger a rebuild in Jenkins. I have tested a lot integration gitea and jenkins.

The most simple method to trigger a rebuild in jenkins would be a GET web-hook following this schema: https://JENKINS-HOST/job/MY-PROJECT/build?token=MY-TOKEN

The only web-hook integrated is the "Gitea" hook. It allows sending the hook as GET request. unfortunately this results in the following response from jenkins:

<h1>Bad Message 431</h1><pre>reason: Request Header Fields Too Large</pre>

I think it would be good to have an separate option for the gitea web-hook GET without body or an additional web-hook provider for jenkins which both are simply sending GET requests without body.

Encountered with the same problem, Request Header Fields Too Large, did you solve it?

[Jeansen]

Same here. When I test the webhook of type gitea for my Jenkins GET endpoint, it works. As soon as it is triggered automatically by a push to my repository, the webhook is triggerd, but I geth a 431 Code. I'd really see an option to withdraw the payload body in GET or have a Jenkins entry added (which will not send any additional data).

[Jeansen]

I've hacked together a simple script and Systemd service that will cut off the payload and forward the webhook. It's a workaround, but it works. At least, for me. Here's the gist: https://gist.github.com/Jeansen/952eac5055870fc2847237b1e5facf0a

[Bastelwombat]

I found another workaround, even simpler than that of @Jeansen: Increasing the maximum acceptable header size for Jenkins. E.g., by adding JENKINS_ARGS="--requestHeaderSize=258140" to the environment variables passed to the Jenkins container.