Gitea fails to complete all checks with more than 1 pattern in "Enable status check" #12604

New Issue

GiteaMirror · 2025-11-02T10:15:48-06:00

GiteaMirror commented

2025-11-02 10:15:48 -06:00

Originally created by @makar112233 on GitHub (Mar 6, 2024).

Description

Hello.
I have a branch, which is protected with setting "Enable status check" and Build server, which is sending statuses of build in Gitea.
When I set only one pattern in a field, all checks are considered successful.
When I set multiply patterns in a filed, I got an error "Some required checks are missing"
You can see it on screenshots.

Gitea Version

1.21.7

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

Multiply pattern

PR checks failed

Single patterns

PR checks successful

Git Version

latest

Operating System

linux

How are you running Gitea?

self-hosted

Database

PostgreSQL

Originally created by @makar112233 on GitHub (Mar 6, 2024). ### Description Hello. I have a branch, which is protected with setting "Enable status check" and Build server, which is sending statuses of build in Gitea. When I set **only one** pattern in a field, all checks are considered successful. When I set **multiply** patterns in a filed, I got an error "Some required checks are missing" You can see it on screenshots. ### Gitea Version 1.21.7 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots Multiply pattern ![sc1](https://github.com/go-gitea/gitea/assets/122980447/648fa3fb-c455-463a-8c5d-9943f5342767) PR checks failed ![sc2](https://github.com/go-gitea/gitea/assets/122980447/2ac27363-9d01-4d75-b0dd-2d569274d363) Single patterns ![sc3](https://github.com/go-gitea/gitea/assets/122980447/d6802845-2bcb-4d02-b6ce-3f78c7a5c105) PR checks successful ![sc4](https://github.com/go-gitea/gitea/assets/122980447/6589302c-b4f5-484b-904e-4d6770189073) ### Git Version latest ### Operating System linux ### How are you running Gitea? self-hosted ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 10:15:48 -06:00

GiteaMirror closed this issue

2025-11-02 10:15:48 -06:00

GiteaMirror commented

2025-11-02 10:15:49 -06:00

@wxiaoguang commented on GitHub (Mar 6, 2024):

Maybe there could be a workaround, for example, use these rules?

*Compile*
*Build amd64*
*Build el8*

(duplicate the Build)

Haven't tested it, but the bug seems to be caused by unmatched rules count & matched count.

Update:

Another question: are these patterns good enough to use?

Suppose the check rules are:

*Compile*
*Build*

there are some results:

Task1 Compile
Task2 Build
Task3 non-related

It passes the check.

Then if the results are:

Task1 Compile
Task2 Error ....
Task3 non-related Build ....

Then Task1 & Task3 make the results pass the check, but actually the Task2 should be "required".

IMO the best practice should be "clearly define the check rules", then there won't be bugs.

@wxiaoguang commented on GitHub (Mar 6, 2024): Maybe there could be a workaround, for example, use these rules? ``` *Compile* *Build amd64* *Build el8* ``` (duplicate the `Build`) Haven't tested it, but the bug seems to be caused by unmatched rules count & matched count. ---- Update: Another question: are these patterns good enough to use? Suppose the check rules are: ``` *Compile* *Build* ``` there are some results: ``` Task1 Compile Task2 Build Task3 non-related ``` It passes the check. Then if the results are: ``` Task1 Compile Task2 Error .... Task3 non-related Build .... ``` Then Task1 & Task3 make the results pass the check, but actually the Task2 should be "required". IMO the best practice should be "clearly define the check rules", then there won't be bugs.

GiteaMirror commented

2025-11-02 10:15:49 -06:00

@makar112233 commented on GitHub (Mar 6, 2024):

@wxiaoguang may be I didn’t understand the question, but in the field “Status check patterns” you need to write build tasks names, not statuses.
Example:
My build server send to Gitea status of these tasks, named:

Task1 Compile
Task2 Build
Task3 non-related

and in the field “Status check patterns” I need to specify

*Compile*
*Build*

It means that if Task1 and Task2 statuses will be “OK”, I would be able to merge.
But now this rule works only for one pattern. See screenshots below.

@makar112233 commented on GitHub (Mar 6, 2024): @wxiaoguang may be I didn’t understand the question, but in the field “Status check patterns” you need to write build tasks names, not statuses. Example: My build server send to Gitea status of these tasks, named: ``` Task1 Compile Task2 Build Task3 non-related ``` and in the field “Status check patterns” I need to specify ``` *Compile* *Build* ``` It means that if Task1 and Task2 statuses will be “OK”, I would be able to merge. But now this rule works only for one pattern. See screenshots below.

GiteaMirror commented

2025-11-02 10:15:49 -06:00

@wxiaoguang commented on GitHub (Mar 6, 2024):

I meant that in you case, there are 2 patterns to match 3 results. Could you try this one?

*Compile*
*Build amd64*
*Build el8*

Use 3 rules to match 3 results, maybe it could be a workaround.

@wxiaoguang commented on GitHub (Mar 6, 2024): I meant that in you case, there are 2 patterns to match 3 results. Could you try this one? ``` *Compile* *Build amd64* *Build el8* ``` Use 3 rules to match 3 results, maybe it could be a workaround.

GiteaMirror commented

2025-11-02 10:15:50 -06:00

@wxiaoguang commented on GitHub (Mar 6, 2024):

The changed behavior is from #29143, because the old behavior is considered to be a "bug".

If I understand correctly, suppose there are some results:

Task1 Compile
Task2 Build amd64
Task3 Build el8

And the rules are:

*Compile*
*Build*

Before 29143, then the blow cases all pass:

Task1 Compile
Task2 Build amd64
(Task3 fails)

Task1 Compile
(Task2 fails)
Task3 Build el8

Task1 Compile
Task2 Build amd64
Task3 Build el8

After 29143, by using 3 rules:

*Compile*
*Build amd64*
*Build el8*

Only the result with all tasks succeeding is considered to pass.

@wxiaoguang commented on GitHub (Mar 6, 2024): The changed behavior is from #29143, because the old behavior is considered to be a "bug". If I understand correctly, suppose there are some results: ``` Task1 Compile Task2 Build amd64 Task3 Build el8 ``` And the rules are: ``` *Compile* *Build* ``` Before 29143, then the blow cases all pass: ``` Task1 Compile Task2 Build amd64 (Task3 fails) ``` ``` Task1 Compile (Task2 fails) Task3 Build el8 ``` ``` Task1 Compile Task2 Build amd64 Task3 Build el8 ``` ---- After 29143, by using 3 rules: ``` *Compile* *Build amd64* *Build el8* ``` Only the result with all tasks succeeding is considered to pass.

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