branch protection status check pattern #13919

Closed
opened 2025-11-02 10:57:16 -06:00 by GiteaMirror · 3 comments
Owner

Originally created by @gzzi on GitHub (Jan 6, 2025).

Description

Hi,

I have a branch protection status check pattern issue. My pattern use a glob and is **/*@(code_style|affected). On the setting page, I see that my CI is marked as match (see first screenshot). But on pull request view same CI passed but a extra line is added with the pattern and written as required (see second screenshot).

Gitea Version

1.22.6

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

image

image

Git Version

No response

Operating System

No response

How are you running Gitea?

unsure but I think it's docker image

Database

None

Originally created by @gzzi on GitHub (Jan 6, 2025). ### Description Hi, I have a branch protection status check pattern issue. My pattern use a glob and is `**/*@(code_style|affected)`. On the setting page, I see that my CI is marked as match (see first screenshot). But on pull request view same CI passed but a extra line is added with the pattern and written as required (see second screenshot). ### Gitea Version 1.22.6 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ![image](https://github.com/user-attachments/assets/1e7f256f-33ed-49f9-a73a-cbe03ea0bf6c) ![image](https://github.com/user-attachments/assets/0e546bb3-b2ad-4dac-8035-05cac7f73419) ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? unsure but I think it's docker image ### Database None
GiteaMirror added the type/bug label 2025-11-02 10:57:16 -06:00
Author
Owner

@Zettat123 commented on GitHub (Jan 6, 2025):

Gitea uses two different libs to test glob patterns.

On the branch protection setting page (the first screenshot), we test the pattern with js code.
40765b5d45/web_src/js/features/repo-settings.ts (L100-L117)

On the pull request page (the second screenshot), we test the pattern with go code.
40765b5d45/routers/web/repo/pull.go (L481-L496)

So I think the cause of this bug may be related to the go glob library we are using (gobwas/glob).


As a workaround, maybe you could use two patterns

**/*code_style
**/*affected
@Zettat123 commented on GitHub (Jan 6, 2025): Gitea uses two different libs to test glob patterns. On the branch protection setting page (the first screenshot), we test the pattern with js code. https://github.com/go-gitea/gitea/blob/40765b5d45f1bcde7193b6273875707ff238cf92/web_src/js/features/repo-settings.ts#L100-L117 On the pull request page (the second screenshot), we test the pattern with go code. https://github.com/go-gitea/gitea/blob/40765b5d45f1bcde7193b6273875707ff238cf92/routers/web/repo/pull.go#L481-L496 So I think the cause of this bug may be related to the go glob library we are using (`gobwas/glob`). --- As a workaround, maybe you could use two patterns ``` **/*code_style **/*affected ```
Author
Owner

@TheFox0x7 commented on GitHub (Jan 6, 2025):

go glob library doesn't support extended syntax (https://github.com/gobwas/glob/issues/3) and @(...) is part of extended one according to bash man:

If the extglob shell option is enabled using the shopt builtin, the shell recognizes several extended pattern matching operators.
[...]
@(pattern-list)
Matches one of the given patterns.

There are two options for solving this as far as I can see:

  1. Fix go library to support extended pattern (or replace it with one that has)
  2. Disable extended syntax for minimatch

Second one is obviously easier and I can make a PR for this.

@TheFox0x7 commented on GitHub (Jan 6, 2025): go glob library doesn't support extended syntax (https://github.com/gobwas/glob/issues/3) and `@(...)` is part of extended one according to [bash man](https://www.gnu.org/software/bash/manual/html_node/Pattern-Matching.html): > If the extglob shell option is enabled using the shopt builtin, the shell recognizes several extended pattern matching operators. > [...] > @(pattern-list) Matches one of the given patterns. There are two options for solving this as far as I can see: 1. Fix go library to support extended pattern (or replace it with one that has) 2. Disable extended syntax for minimatch Second one is obviously easier and I can make a PR for this.
Author
Owner

@gzzi commented on GitHub (Jan 7, 2025):

By looking at go glob I found out that it was in fact possible without using extended pattern. The syntax is:

**/*{affected,code_style}
@gzzi commented on GitHub (Jan 7, 2025): By looking at go glob I found out that it was in fact possible without using extended pattern. The syntax is: ``` **/*{affected,code_style} ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#13919