Jenkins Git plugin webhook support #8361

New Issue

GiteaMirror · 2025-11-02T08:03:40-06:00

GiteaMirror commented

2025-11-02 08:03:40 -06:00

Originally created by @fhuberts on GitHub (Jan 16, 2022).

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:

Screenshots

No response

Originally created by @fhuberts on GitHub (Jan 16, 2022). ### 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_

GiteaMirror added the type/proposal label 2025-11-02 08:03:40 -06:00

GiteaMirror commented

2025-11-02 08:03:41 -06:00

@fhuberts commented on GitHub (Jan 16, 2022):

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

@fhuberts commented on GitHub (Jan 16, 2022): It would be nice if this was added to the current stable release.

GiteaMirror commented

2025-11-02 08:03:41 -06:00

@beyerjsb commented on GitHub (Feb 18, 2022):

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.

@beyerjsb commented on GitHub (Feb 18, 2022): 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.

GiteaMirror commented

2025-11-02 08:03:41 -06:00

@fhuberts commented on GitHub (Feb 18, 2022):

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.

@fhuberts commented on GitHub (Feb 18, 2022): 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.

GiteaMirror commented

2025-11-02 08:03:41 -06:00

@beyerjsb commented on GitHub (Feb 18, 2022):

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.

@beyerjsb commented on GitHub (Feb 18, 2022): 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.

GiteaMirror commented

2025-11-02 08:03:41 -06:00

@fhuberts commented on GitHub (Feb 18, 2022):

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

@fhuberts commented on GitHub (Feb 18, 2022): That would work as well for this use-case. (I'm still keeping my code in place for more complex use-cases though ;-) )

GiteaMirror commented

2025-11-02 08:03:41 -06:00

@lunny commented on GitHub (Feb 18, 2022):

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

@lunny commented on GitHub (Feb 18, 2022): How about use https://github.com/jenkinsci/gitea-plugin directly?

GiteaMirror commented

2025-11-02 08:03:41 -06:00

@fhuberts commented on GitHub (Feb 18, 2022):

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 commented on GitHub (Feb 18, 2022): However, 1 small advantage of my solution is that the webhook is the same for every repo. But that is just my personal preference.

GiteaMirror commented

2025-11-02 08:03:42 -06:00

@fhuberts commented on GitHub (Feb 18, 2022):

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

I have no need for that currently.

@fhuberts commented on GitHub (Feb 18, 2022): > How about use https://github.com/jenkinsci/gitea-plugin directly? I have no need for that currently.

GiteaMirror commented

2025-11-02 08:03:42 -06:00

@beyerjsb commented on GitHub (Feb 18, 2022):

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.

@beyerjsb commented on GitHub (Feb 18, 2022): > 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.

GiteaMirror commented

2025-11-02 08:03:42 -06:00

@weberhofer commented on GitHub (Aug 9, 2023):

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.

@weberhofer commented on GitHub (Aug 9, 2023): 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.

GiteaMirror commented

2025-11-02 08:03:42 -06:00

@arslantu commented on GitHub (Nov 4, 2023):

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?

@arslantu commented on GitHub (Nov 4, 2023): > 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?

GiteaMirror commented

2025-11-02 08:03:42 -06:00

@Jeansen commented on GitHub (Feb 14, 2024):

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 commented on GitHub (Feb 14, 2024): 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).

GiteaMirror commented

2025-11-02 08:03:43 -06:00

@Jeansen commented on GitHub (Feb 14, 2024):

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

@Jeansen commented on GitHub (Feb 14, 2024): 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

GiteaMirror commented

2025-11-02 08:03:43 -06:00

@Bastelwombat commented on GitHub (Mar 16, 2024):

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.

@Bastelwombat commented on GitHub (Mar 16, 2024): 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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8361