Mergeable property on API pull request's struct are currently wrong #11212

New Issue

GiteaMirror · 2025-11-02T09:30:58-06:00

GiteaMirror commented

2025-11-02 09:30:58 -06:00

Originally created by @bilderbuchi on GitHub (Jul 12, 2023).

@Gusted wrote in #19457 that:

Mergeable property on API pull request's struct are currently wrong(because incorrect value being set), so anyone who uses the API and uses that property to determine if a PR is conflicting is currently affected.

Given we don't expose which files are conflicting with base branch(which is gitea's internal check to determine conflicting PR's) they don't have any other way to determine if a PR is conflicting with base branch.

Originally posted by @Gusted in https://github.com/go-gitea/gitea/issues/19457#issuecomment-1105801652

I believe that bug is still present, but I could not find an issue for it already.
I observe this problem on a Gitea 1.19.3 deployment, in that as as soon as a PR becomes non-mergeable once, the mergeable field of the request sent from Gitea to our CI seems to "stick" at false and not toggle back to mergeable=true any more, even after a commit fixing the merge conflict has been pushed.

This forced us to ignore the mergeable field of the request sent from Gitea to our CI, otherwise we would not get builds anymore after a merge conflict.

Originally created by @bilderbuchi on GitHub (Jul 12, 2023). @Gusted wrote in #19457 that: >`Mergeable` property on API pull request's struct are currently wrong(because incorrect value being set), so anyone who uses the API and uses that property to determine if a PR is conflicting is currently affected. > >Given we don't expose which files are conflicting with base branch(which is gitea's internal check to determine conflicting PR's) they don't have any other way to determine if a PR is conflicting with base branch. _Originally posted by @Gusted in https://github.com/go-gitea/gitea/issues/19457#issuecomment-1105801652_ I believe that bug is still present, but I could not find an issue for it already. I observe this problem on a Gitea 1.19.3 deployment, in that as as soon as a PR becomes non-mergeable once, the `mergeable` field of the request sent from Gitea to our CI seems to "stick" at `false` and not toggle back to `mergeable=true` any more, even after a commit fixing the merge conflict has been pushed. This forced us to ignore the `mergeable` field of the request sent from Gitea to our CI, otherwise we would not get builds anymore after a merge conflict.

GiteaMirror added the topic/api type/bug labels 2025-11-02 09:30:58 -06:00

GiteaMirror commented

2025-11-02 09:30:59 -06:00

@lunny commented on GitHub (May 2, 2024):

Duplicate of #19755

@lunny commented on GitHub (May 2, 2024): Duplicate of #19755

GiteaMirror commented

2025-11-02 09:30:59 -06:00

@bilderbuchi commented on GitHub (May 2, 2024):

Duplicate of #19755

@lunny why do you think that? That report is about the timing of too early webhook firing vs. mergeable checks, this present issue is about the mergeable attribute not being updated at all. Two separate things IMO, don't you agree?

This comment https://github.com/go-gitea/gitea/issues/19755#issuecomment-1237219282 over in #19755 actually refers to this issue here.

@bilderbuchi commented on GitHub (May 2, 2024): > Duplicate of #19755 @lunny why do you think that? That report is about the timing of too early webhook firing vs. mergeable checks, this present issue is about the `mergeable` attribute not being updated **at all**. Two separate things IMO, don't you agree? This comment https://github.com/go-gitea/gitea/issues/19755#issuecomment-1237219282 over in #19755 actually refers to this issue here.

GiteaMirror commented

2025-11-02 09:30:59 -06:00

@lunny commented on GitHub (May 2, 2024):

Have you checked that the mergable never been corrected? Maybe you check it too early? If that, I think these are two different problems.

@lunny commented on GitHub (May 2, 2024): Have you checked that the `mergable` never been corrected? Maybe you check it too early? If that, I think these are two different problems.

GiteaMirror commented

2025-11-02 09:30:59 -06:00

@bilderbuchi commented on GitHub (May 3, 2024):

I just checked on an 1.21.10 deployment and, yes, "mergeable": false still seems to stick:

I have a branch with a merge conflict (with the UI indicating that).
I fix the conflict locally and push a merge commit. "mergeable": false in the webhook, presumably due to #19755
UI does not indicate a merge conflict any more
I push another commit with some change. The webhook still has "mergeable": false in the payload. It can't be too early because see the previous bullet, and several minutes passed (it's a small codebase).

Of course, it's impossible to prove that this is "never" updated. A night has passed now, and another subsequent commit still has an incorrect "mergeable": false, though. ;-)

@bilderbuchi commented on GitHub (May 3, 2024): I just checked on an 1.21.10 deployment and, yes, `"mergeable": false` still seems to stick: * I have a branch with a merge conflict (with the UI indicating that). * I fix the conflict locally and push a merge commit. `"mergeable": false` in the webhook, presumably due to #19755 * UI does not indicate a merge conflict any more * I push another commit with some change. The webhook still has `"mergeable": false` in the payload. It can't be too early because see the previous bullet, and several minutes passed (it's a small codebase). Of course, it's impossible to prove that this is "never" updated. A night has passed now, and another subsequent commit still has an incorrect `"mergeable": false`, though. ;-)

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#11212

Mergeable property on API pull request's struct are currently wrong #11212

`Mergeable` property on API pull request's struct are currently wrong #11212