github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-21 14:06:26 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

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

New Issue
Closed
opened 2025-11-02 11:02:34 -06:00 by GiteaMirror · 15 comments
GiteaMirror commented 2025-11-02 11:02:34 -06:00
Owner
Copy Link

Originally created by @phoedos on GitHub (Feb 4, 2025).

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: *

Image

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.

Image

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.
Image

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

Originally created by @phoedos on GitHub (Feb 4, 2025). ### 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: * ![Image](https://github.com/user-attachments/assets/d9578033-332f-47e3-9435-02a00191cb85) 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. ![Image](https://github.com/user-attachments/assets/6716d945-2d79-4802-bdf1-728aefc319af) 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. ![Image](https://github.com/user-attachments/assets/cc2a2f7a-a149-4b48-96be-37c580bf6700) 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
GiteaMirror added the issue/needs-feedbackissue/not-a-bug labels 2025-11-02 11:02:34 -06:00
GiteaMirror commented 2025-11-02 11:02:35 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Feb 4, 2025):

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)

@wxiaoguang commented on GitHub (Feb 4, 2025): 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
GiteaMirror commented 2025-11-02 11:02:35 -06:00
Author
Owner
Copy Link

@phoedos commented on GitHub (Feb 6, 2025):

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
@phoedos commented on GitHub (Feb 6, 2025): 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
GiteaMirror commented 2025-11-02 11:02:35 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Feb 6, 2025):

According to: https://github.com/go-gitea/gitea/issues/33302#issuecomment-2639340884

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

@wxiaoguang commented on GitHub (Feb 6, 2025): According to: https://github.com/go-gitea/gitea/issues/33302#issuecomment-2639340884 > 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
GiteaMirror commented 2025-11-02 11:02:35 -06:00
Author
Owner
Copy Link

@phoedos commented on GitHub (Feb 6, 2025):

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?

@phoedos commented on GitHub (Feb 6, 2025): 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?
GiteaMirror commented 2025-11-02 11:02:36 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 10, 2025):

@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?

@lunny commented on GitHub (Feb 10, 2025): @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?
GiteaMirror commented 2025-11-02 11:02:36 -06:00
Author
Owner
Copy Link

@phoedos commented on GitHub (Feb 10, 2025):

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.

@phoedos commented on GitHub (Feb 10, 2025): 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.
GiteaMirror commented 2025-11-02 11:02:37 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 10, 2025):

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

@lunny commented on GitHub (Feb 10, 2025): > Dear [@lunny](https://github.com/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
GiteaMirror commented 2025-11-02 11:02:37 -06:00
Author
Owner
Copy Link

@phoedos commented on GitHub (Feb 10, 2025):

Dear @lunny
no sys, no repo webhooks configured,

Image

only ORG one

Image

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

@phoedos commented on GitHub (Feb 10, 2025): Dear @lunny no sys, no repo webhooks configured, ![Image](https://github.com/user-attachments/assets/f4cf5457-1b06-474a-910d-e6b559898e89) only ORG one ![Image](https://github.com/user-attachments/assets/4795571c-b06a-4e43-ae26-bf7ea01ceecd) and this configuration disable branch in Jenkins during commit when PR is active
GiteaMirror commented 2025-11-02 11:02:37 -06:00
Author
Owner
Copy Link

@phoedos commented on GitHub (Feb 10, 2025):

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

Image

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

Image

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

Image

@phoedos commented on GitHub (Feb 10, 2025): Action1: just make a commit in Branch which trigger Jenkins build ![Image](https://github.com/user-attachments/assets/bee32100-667b-46cc-862f-66d14d3012f1) Action2: Make PR via Gitea interface test->master branch and stay it active (uclosed) ![Image](https://github.com/user-attachments/assets/3f08beb9-9ff6-43db-bd6c-28ef7504b25b) 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 ![Image](https://github.com/user-attachments/assets/4629b496-3df9-46d6-b54a-69bcbfd233ea)
GiteaMirror commented 2025-11-02 11:02:37 -06:00
Author
Owner
Copy Link

@yp05327 commented on GitHub (Feb 10, 2025):

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

@yp05327 commented on GitHub (Feb 10, 2025): Can you also provide the history records (Recent Deliveries) in Gitea side? The required information is the headers of these requests.
GiteaMirror commented 2025-11-02 11:02:37 -06:00
Author
Owner
Copy Link

@phoedos commented on GitHub (Feb 11, 2025):

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

webhooks.txt

@phoedos commented on GitHub (Feb 11, 2025): dear @yp05327 here is txt with webhook data. PS: as you can see, headers are always similar. [webhooks.txt](https://github.com/user-attachments/files/18745962/webhooks.txt)
GiteaMirror commented 2025-11-02 11:02:37 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 11, 2025):

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?

@lunny commented on GitHub (Feb 11, 2025): 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?
GiteaMirror commented 2025-11-02 11:02:37 -06:00
Author
Owner
Copy Link

@yp05327 commented on GitHub (Feb 11, 2025):

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. :)

@yp05327 commented on GitHub (Feb 11, 2025): 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. :)
GiteaMirror commented 2025-11-02 11:02:38 -06:00
Author
Owner
Copy Link

@phoedos commented on GitHub (Feb 12, 2025):

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!

Image

@phoedos commented on GitHub (Feb 12, 2025): 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! ![Image](https://github.com/user-attachments/assets/49df50ad-cc8f-4042-8d9b-baef42b19b4b)
GiteaMirror commented 2025-11-02 11:02:38 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 12, 2025):

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!

Image

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

@lunny commented on GitHub (Feb 12, 2025): > 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! > > ![Image](https://github.com/user-attachments/assets/49df50ad-cc8f-4042-8d9b-baef42b19b4b) Thank you for sharing! This could be really helpful for others facing similar issues.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/needs-feedback issue/not-a-bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#14091
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?