gitea1.23.3: wrong PR logic & disabled webhooks still working

[phoedos]

Description

Hi guys
after upgrading to gitea 1.22.6->1.23.1 have next issue related with Pull Requests, Gitea and Jenkins integration
Jenkins version - latest jenkins:2.495-jdk21
Gitea jenkins plugin - latest 234.v60def593ec50

Inside gitea ORG have next webhook settings:
url: https://jenkinsurl/gitea-webhook/post
method: POST
POST content type: application/json
Trigger on: custom events [NO PR actions are activated]

• Create
• Delete
• Push
• Repository
  Branch filter: *

Inside org I have a repo with 'main' and 'test' branches
Later, inside gitea interface I make a PR test->main branch and stay it unclosed (imagine it's under review for another developer)

Now I continue work on 'test' branch and make some new commits .

expected result: gitea will send a webhook, jenkins run a pipeline on 'test' branch according to jenkinsfile logic
actual resut: gitea add new commit to PR, test branch (inside jenkins) is disabled by Gitea.

Why This Behavior Seems Incorrect:
Unexpected Webhook Behavior – Gitea sends a PR webhook to Jenkins even though PR webhooks are explicitly disabled.
Forced PR Updates – New commits to test are automatically added to the existing open PR, making it impossible to continue working on test without affecting the PR.

Regression from 1.22.6 – This behavior did not occur in Gitea 1.22.6 and appears to be a new issue introduced in 1.23.1.

Impact:
Developers cannot work on test independently after opening a PR.
PRs may receive uncontrolled code changes, which could result in unintended code being merged into main.

Request for Investigation:
Could you please confirm if this is an intended change in Gitea 1.23.1 or a potential bug? If it is an intended change, is there a way to prevent this behavior?

Gitea Version

1.23.1

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

docker-compose

Database

PostgreSQL

[wxiaoguang]

Maybe related to:

-> Gitea submits webhooks on "status" event, even if webhook is defined only for "push" #33302
-> Add tests for webhook and fix some webhook bugs (#33396) #33442

Could you try 1.23-nightly? (it is a stable release and will be 1.23.2 soon)

• https://hub.docker.com/r/gitea/gitea/tags?name=1.23-nightly

[phoedos]

Dear @wxiaoguang
today tested on 1.23.3 - no changes, logic is still the same:

• during active PR new commits in branch auto-added to PR
• gitea disable branch in Jenkins, auto-builds from branch do not start until PR is active

[wxiaoguang]

According to: #33302 (comment)

There hasn't been any event after I edited the webhook settings. (basically a no-op):
Enable Statuses -> Apply -> Disable Statuses -> Apply

Does it help?

also @lunny

[phoedos]

Dear @wxiaoguang

1. 'Statuses' webhook event wasn't present in interface until I recreated webhook
2. it doesn't matter either 'Statuses'=enabled, either 'Statuses'=disabled, branch in jenkins disables during active PR
3. made experiment with 'Statuses'=disabled

• gitea made 2 webhooks to Jenkins, (on commit action); no webhook on PR made BUT
• diff webhook content before PR and after PR show

diff hookbeforepr.txt hookafterpr.txt
...
<     "open_pr_counter": 0,
---
>     "open_pr_counter": 1,

all other options before, after, compare_url, id, message, url are similar

maybe issue related with gitea jenkins plugin whith incorrect processing of 'open_pr_counter' parameter?

[lunny]

@phoedos Have you tried to upgrade to v1.23.3 and you can reconfigure the webhook to uncheck statuses in the webhook edit UI? Have you tried that?

[phoedos]

Dear @lunny, nice to meet you!
Now I'm running on Gitea 1.23.3. Webhook was deleted and created again. Disabled 'Statuses' option do not help me.
Also tried to enable 'Statuses' - apply; disable 'Statuses' - apply: no result.
Seems that 'Statuses' option checkbox do not work.

[lunny]

Dear @lunny, nice to meet you! Now I'm running on Gitea 1.23.3. Webhook was deleted and created again. Disabled 'Statuses' option do not help me. Also tried to enable 'Statuses' - apply; disable 'Statuses' - apply: no result. Seems that 'Statuses' option checkbox do not work.

Can you check whether there are other level webhooks, like org level and system level webhooks will be triggered. I cannot reproduce in my local machine with v1.23.3

[phoedos]

Dear @lunny
no sys, no repo webhooks configured,

only ORG one

and this configuration disable branch in Jenkins during commit when PR is active

[phoedos]

Action1:
just make a commit in Branch which trigger Jenkins build

Action2:
Make PR via Gitea interface test->master branch and stay it active (uclosed)

Action3:
during active PR make another commit in test branch

expected result:

• build will be triggered with Jenkins

actual result

• jenkins build wasn't triggered
• jenkins 'test' branch is disabled (until PR is active)
• commit added to PR request, no build made
• jenkins will start bulds for 'test' branch only:
  -- when PR merge commit is created
  --when PR is closed

[yp05327]

Can you also provide the history records (Recent Deliveries) in Gitea side?
The required information is the headers of these requests.

[phoedos]

dear @yp05327 here is txt with webhook data.
PS: as you can see, headers are always similar.

webhooks.txt

[lunny]

When you create a new branch, two webhooks will be triggered: one for the branch creation event and another for the commit push event. I reviewed the code again. As far as I know, there hasn’t been any change in this logic between versions 1.22 and 1.23.

When you push a commit, a webhook will be triggered regardless of whether a pull request (PR) is created with the branch as its head or not. This means that even if PR events are disabled, it’s normal for a webhook to be triggered when you push a commit to the head branch of the PR. GitHub exhibits similar behavior.

---

Since all your PR events are disabled, I don't understand why --when PR is closed, jenkins will start bulds for 'test' branch only.

I don't know how it works about gitea disable branch in Jenkins. Gitea just triggered a webhook and no operation to disable branch in Jenkins. Maybe it's a behaviour of the Gitea plugin of Jenkins?

[yp05327]

From the webhooks.txt, the behaviours in Gitea side are all expected.

There are something I can not understand:

• Unexpected Webhook Behavior – Gitea sends a PR webhook to Jenkins even though PR webhooks are explicitly disabled.

What do you mean Gitea sends a PR webhook? Because there are only push events in the text you provided.
If there are some PR related events, it should be a bug as no PR related events are selected.

• jenkins 'test' branch is disabled (until PR is active)

Same to @lunny. There are only push events triggered, so why it is disabled in jenkins?
So maybe there are some other situations that make it be disabled at first. Even Gitea side works well, sends a push event webhook later, but it is already disabled in jenkins, so the pipeline don't work? (This is a guess from me.)

As you also said above:

Make PR via Gitea interface test->master branch and stay it active (uclosed)

So after the PR created, the test branch should be enabled in jenkins?
Then when it is disabled? After the new commit to test branch (Action3) or before?

---

jenkins will start bulds for 'test' branch only:
-- when PR merge commit is created
--when PR is closed

According to webhook.txt, these two cases are worked because the target of push event workflow is main branch not test branch:

webhook after clicking on PR approve inside gitea
....
"ref": "refs/heads/main",
...

The main branch is not disabled, so of cause, it worked.

---

According to the analyzation above, the issue is clear:
The test branch is blocked in jenkins by some unkown reasons during the creation of the PR.
But from Gitea side, only push events are triggered, so it is hard to consider that Gitea takes the initiative to block it.
Maybe you need to test when it is blocked, then figure out why it is blocked.

I hope this analyzation can be helpful to you. :)

[phoedos]

Dear guys,
thank you for your efforts to investigate the issue.
I even made a lab with gitea+jenkins in docker-compose to analyze the reported case.
Found that issue related to Jenkins ORG folder configuration: Discover branches -> Strategy.
Changing settings Only branches that are not also filled as PRs -> All branches solved my issue.
now build is working during active PR. Thank you very much!

[lunny]

Dear guys, thank you for your efforts to investigate the issue. I even made a lab with gitea+jenkins in docker-compose to analyze the reported case. Found that issue related to Jenkins ORG folder configuration: Discover branches -> Strategy. Changing settings Only branches that are not also filled as PRs -> All branches solved my issue. now build is working during active PR. Thank you very much!

Thank you for sharing! This could be really helpful for others facing similar issues.