Move the main logic of `generateTaskContext` and `findTaskNeeds` to the
`services` layer.
This is a part of #32751, since we need the git context and `needs` to
parse the concurrency expressions.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Major changes:
1. do not sync ".keep" file during tests
2. fix incorrect route handler and empty repo handling (backported as #33253 with tests)
3. do not use `RepoRef`: most of the calls are abuses.
4. Use `git.RefType` instead of a new type definition `RepoRefType` on `context`.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
The template should be `repo/migrate/{service type}`
But input element `service` is not in the form.
Related: #33081
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Found while investigating #33210.
This line no longer makes sense because the form field "TagName" is
required, so this would mean that this code path would never be covered.
Because it isn't covered, we end up going down the "update release"
logic where we eventually set `Release.IsTag` to false (meaning it will
now be treated as a release instead of a tag).
This snapshot rewrites the condition to ensure that we aren't trying to
create a tag that already exists.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR fixes inconsistencies between system and default webhooks in the
Gitea API. (See also #26418)
- A system webhook is a webhook that captures events for all
repositories.
- A default webhook is copied to a new repository when it is created.
Before this PR `POST /api/v1/admin/hooks/` creates default webhooks (if
not configured otherwise) and `GET /api/v1/admin/hooks/` returns system
webhooks.
The PR introduces an optional query parameter to `GET
/api/v1/admin/hooks/` to enable selecting if either default, system or
both kind of webhooks should be retrieved. By default the flag is set to
return system webhooks keep current behaviour.
## Examples
### System Webhooks
#### Create
```
POST /api/v1/admin/hooks/
{
"type": "gitea",
"active": false,
"branch_filter": "*",
"events": [ "create", "..." ],
"config": {
"url": "http://...",
"content_type": "json",
"secret": "secret",
"is_system_webhook": true // <-- controls hook type
}
}
```
#### List
```
GET/api/v1/admin/hooks?type=system //type argument is optional here since it's the default
```
#### Others
The other relevant endpoints work as expected by referencing the hook by
id
```
GET /api/v1/admin/hooks/:id
PATCH /api/v1/admin/hooks/:id
DELETE /api/v1/admin/hooks/:id
```
### Default Webhooks
#### Create
```
POST /api/v1/admin/hooks/
{
"type": "gitea",
"active": false,
"branch_filter": "*",
"events": [ "create", "..." ],
"config": {
"url": "http://...",
"content_type": "json",
"secret": "secret",
"is_system_webhook": false // optional, as false is the default value
}
}
```
#### List
```
GET/api/v1/admin/hooks?type=default
```
#### Others
The other relevant endpoints work as expected by referencing the hook by
id
```
GET /api/v1/admin/hooks/:id
PATCH /api/v1/admin/hooks/:id
DELETE /api/v1/admin/hooks/:id
```
1. "blob" is not a "ref", it shouldn't (and not unable to) be handled by
`RepoRefByType`
2. the `/blob/{sha}` handle should use the path param "sha" directly
The `ctx.Repo.RefName` was used to be a "short name", it causes a lot of
ambiguity.
This PR does some refactoring and use `RefFullName` to replace the
legacy `RefName`, and simplify RepoAssignment
~~Waiting for the upload of screenshots~~
I have a good idea about the screenshots. I will do it later.
---------
Co-authored-by: Gary Wang <git@blumia.net>
Resolve#32341
~Depends on #27151~
- [x] It will display a checkbox of deleting the head branch on the pull
request view page when starting an auto-merge task.
- [x] Add permission check before deleting the branch
- [x] Add delete branch comment for those closing pull requests because
of head branch or base branch was deleted.
- [x] Merge `RetargetChildrenOnMerge` and `AddDeletePRBranchComment`
into `service.DeleteBranch`.
Follow #33045. There are two updates on `Set Merged`, which should be in
one transaction.
This also introduced some refactors for changeissuestatus to make it
more clear.
