2
0
Commit Graph

11 Commits

Author SHA1 Message Date
6543
82533f5e11 Add priority to protected branch (#32286)
## Solves

Currently for rules to re-order them you have to alter the creation
date. so you basicly have to delete and recreate them in the right
order. This is more than just inconvinient ...

## Solution

Add a new col for prioritization

## Demo WebUI Video

https://github.com/user-attachments/assets/92182a31-9705-4ac5-b6e3-9bb74108cbd1


---
*Sponsored by Kithara Software GmbH*
2024-11-27 05:41:06 +01:00
6543
8c870a9a8b Optimize branch protection rule loading (#32280)
before if it was nonglob each load would try to glob it and the check
that is not glob ... now we only do that once and no future loading will
trigger it


---
*Sponsored by Kithara Software GmbH*
2024-10-29 15:43:47 +01:00
Tim
01423046c9 Make admins adhere to branch protection rules (#32248)
This introduces a new flag `BlockAdminMergeOverride` on the branch
protection rules that prevents admins/repo owners from bypassing branch
protection rules and merging without approvals or failing status checks.

Fixes #17131

---------

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
2024-10-23 12:39:43 +08:00
Henry Goodman
493b7c2b20 Allow force push to protected branches (#28086)
Fixes #22722 

### Problem
Currently, it is not possible to force push to a branch with branch
protection rules in place. There are often times where this is necessary
(CI workflows/administrative tasks etc).

The current workaround is to rename/remove the branch protection,
perform the force push, and then reinstate the protections.

### Solution
Provide an additional section in the branch protection rules to allow
users to specify which users with push access can also force push to the
branch. The default value of the rule will be set to `Disabled`, and the
UI is intuitive and very similar to the `Push` section.

It is worth noting in this implementation that allowing force push does
not override regular push access, and both will need to be enabled for a
user to force push.

This applies to manual force push to a remote, and also in Gitea UI
updating a PR by rebase (which requires force push)

This modifies the `BranchProtection` API structs to add:
- `enable_force_push bool`
- `enable_force_push_whitelist bool`
- `force_push_whitelist_usernames string[]`
- `force_push_whitelist_teams string[]`
- `force_push_whitelist_deploy_keys bool`

### Updated Branch Protection UI:

<img width="943" alt="image"
src="https://github.com/go-gitea/gitea/assets/79623665/7491899c-d816-45d5-be84-8512abd156bf">

### Pull Request `Update branch by Rebase` option enabled with source
branch `test` being a protected branch:


![image](https://github.com/go-gitea/gitea/assets/79623665/e018e6e9-b7b2-4bd3-808e-4947d7da35cc)
<img width="1038" alt="image"
src="https://github.com/go-gitea/gitea/assets/79623665/57ead13e-9006-459f-b83c-7079e6f4c654">

---------

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
2024-07-05 18:21:56 +00:00
Jimmy Praet
a8a6cd51ec Add branch protection setting for ignoring stale approvals (#28498)
Fixes #27114.

* In Gitea 1.12 (#9532), a "dismiss stale approvals" branch protection
setting was introduced, for ignoring stale reviews when verifying the
approval count of a pull request.
* In Gitea 1.14 (#12674), the "dismiss review" feature was added.
* This caused confusion with users (#25858), as "dismiss" now means 2
different things.
* In Gitea 1.20 (#25882), the behavior of the "dismiss stale approvals"
branch protection was modified to actually dismiss the stale review.

For some users this new behavior of dismissing the stale reviews is not
desirable.

So this PR reintroduces the old behavior as a new "ignore stale
approvals" branch protection setting.

---------

Co-authored-by: delvh <dev.lh@web.de>
2024-01-15 07:20:01 +00:00
wxiaoguang
932f620c18 Refactor some legacy code and remove unused code (#28622)
1. use slices.Contains, remove Int64sContains
2. use HashEmail, remove base.EncodeMD5
3. remove BasicAuthEncode, IsLetter
2023-12-28 09:38:59 +00:00
Lunny Xiao
0ffaad2251 Remove GetByBean method because sometimes it's danger when query condition parameter is zero and also introduce new generic methods (#28220)
The function `GetByBean` has an obvious defect that when the fields are
empty values, it will be ignored. Then users will get a wrong result
which is possibly used to make a security problem.

To avoid the possibility, this PR removed function `GetByBean` and all
references.
And some new generic functions have been introduced to be used.

The recommand usage like below.

```go
// if query an object according id
obj, err := db.GetByID[Object](ctx, id)
// query with other conditions
obj, err := db.Get[Object](ctx, builder.Eq{"a": a, "b":b})
```
2023-12-07 15:27:36 +08:00
JakobDev
54838182eb Updates to the API for archived repos (#27149) 2023-09-21 23:43:29 +00:00
CaiCandong
f46859a6cb Replace util.SliceXxx with slices.Xxx (#26958) 2023-09-07 09:37:47 +00:00
yp05327
0a942f64cd Rename repo.GetOwner to repo.LoadOwner (#22967)
Fixes https://github.com/go-gitea/gitea/issues/22963

---------

Co-authored-by: Yarden Shoham <hrsi88@gmail.com>
2023-02-18 20:11:03 +08:00
Lunny Xiao
9f569b0039 Supports wildcard protected branch (#20825)
This PR introduce glob match for protected branch name. The separator is
`/` and you can use `*` matching non-separator chars and use `**` across
separator.

It also supports input an exist or non-exist branch name as matching
condition and branch name condition has high priority than glob rule.

Should fix #2529 and #15705

screenshots

<img width="1160" alt="image"
src="https://user-images.githubusercontent.com/81045/205651179-ebb5492a-4ade-4bb4-a13c-965e8c927063.png">

Co-authored-by: zeripath <art27@cantab.net>
2023-01-16 16:00:22 +08:00