gitea/models/migrations
Henry Goodman 12cb1d2998
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
..
base Enable more revive linter rules (#30608) 2024-04-22 11:48:42 +00:00
fixtures Remove If Exist check on migration for mssql because that syntax required SQL server 2016 (#30894) 2024-05-11 22:16:09 +08:00
v1_6 Enable more revive linter rules (#30608) 2024-04-22 11:48:42 +00:00
v1_7 Rename Sync2 -> Sync (#26479) 2023-08-13 21:17:21 +02:00
v1_8 Rename Sync2 -> Sync (#26479) 2023-08-13 21:17:21 +02:00
v1_9 Enable more revive linter rules (#30608) 2024-04-22 11:48:42 +00:00
v1_10 Rename Sync2 -> Sync (#26479) 2023-08-13 21:17:21 +02:00
v1_11 Enable more revive linter rules (#30608) 2024-04-22 11:48:42 +00:00
v1_12 Rename Sync2 -> Sync (#26479) 2023-08-13 21:17:21 +02:00
v1_13 Rename Sync2 -> Sync (#26479) 2023-08-13 21:17:21 +02:00
v1_14 Use crypto/sha256 (#29386) 2024-02-25 13:32:13 +00:00
v1_15 Rename Sync2 -> Sync (#26479) 2023-08-13 21:17:21 +02:00
v1_16 Fix some bug on migrations (#30647) 2024-04-24 01:58:24 +00:00
v1_17 Update misspell to 0.5.1 and add misspellings.csv (#30573) 2024-04-27 08:03:49 +00:00
v1_18 Fix wrong table name (#30557) 2024-04-23 03:00:57 +00:00
v1_19 Rename Sync2 -> Sync (#26479) 2023-08-13 21:17:21 +02:00
v1_20 Enable more revive linter rules (#30608) 2024-04-22 11:48:42 +00:00
v1_21 handle repository.size column being NULL in migration v263 (#28336) 2023-12-05 14:31:13 +00:00
v1_22 Fix the possible migration failure on 286 with postgres 16 (#31209) 2024-06-02 03:01:08 +00:00
v1_23 Allow force push to protected branches (#28086) 2024-07-05 18:21:56 +00:00
migrations.go Allow force push to protected branches (#28086) 2024-07-05 18:21:56 +00:00