Although it would be possible to modify these files, it would create
conflicts when rebasing. Instead, this commit removes them entirely
and another commit can start from scratch, borrowing content from the
original files.
The drawback of this approach is that some content updates from Gitea
that also need updating in Forgejo will have to be copy/pasted
instead of being merged.
(cherry picked from commit eb85782115)
(cherry picked from commit 34401f2004)
(cherry picked from commit ef43b1c691)
(cherry picked from commit d17fe25e2f)
(cherry picked from commit c4f688fe54)
(cherry picked from commit 4628d06534)
(cherry picked from commit 4a2a956138)
(cherry picked from commit b8f57065df)
(cherry picked from commit c4a1a695ff)
(cherry picked from commit a6a768de7d)
(cherry picked from commit 5bd9b17952)
Backport #24231 by @sillyguodong
Close#24213
Replace #23830
#### Cause
- Before, in order to making PR can get latest commit after reopening,
the `ref`(${REPO_PATH}/refs/pull/${PR_INDEX}/head) of evrey closed PR
will be updated when pushing commits to the `head branch` of the closed
PR.
#### Changes
- For closed PR , won't perform these behavior: insert`comment`, push
`notification` (UI and email), exectue
[pushToBaseRepo](7422503341/services/pull/pull.go (L409))
function and trigger `action` any more when pushing to the `head branch`
of the closed PR.
- Refresh the reference of the PR when reopening the closed PR (**even
if the head branch has been deleted before**). Make the reference of PR
consistent with the `head branch`.
Co-authored-by: sillyguodong <33891828+sillyguodong@users.noreply.github.com>
Backport #24573
Help some users like #16832#1851
There are many users reporting similar problem: if the SECRET_KEY
mismatches, some operations (like 2FA login) only reports unclear 500
error and unclear "base64 decode error" log （some maintainers ever spent
a lot of time on debugging such problem)
The SECRET_KEY was not well-designed and it is also a kind of technical
debt. Since it couldn't be fixed easily, it's good to add clearer error
messages, then at least users could know what the real problem is.
Backport #24536 by @sillyguodong
close#24449
The unit of `Actions` should be contorlled not only by
`repository.DISABLED_REPO_UNITS` but also by `actions.ENABLED`
in the `app.ini`.
Previously, the permission of the team's `Actions` unit was not
controlled by `actions.Enabled`. So, even if the user sets
`actions.Enabled` to false, he can still select the permission of the
`Actions` unit for the team.
This PR makes the permissions of the team's `Actions` unit also
controlled by `actions.Enabled`. Just append`TypeActions` into
`DisabledRepoUnits` slice when initializing if `actions.Enabled` is
false.
### Changes:
If `Actions` is set disbaled in `app.ini`, like below:
```yaml
[actions]
ENABLED = false
```
1. If user try to create/edit a team, will prompt user that `Actions` is
disbaled.
2. `actions` is not displayed in the sidebar on the team details page
Co-authored-by: sillyguodong <33891828+sillyguodong@users.noreply.github.com>
Backport #23062
Backport #24515Fix#23617
This notably brings support for GOARCH=loong64, among other fixes.
This PR also fix bleve search architecture problem.
---------
Signed-off-by: WANG Xuerui <xen0n@gentoo.org>
Co-authored-by: WÁNG Xuěruì <1175567+xen0n@users.noreply.github.com>
Co-authored-by: zeripath <art27@cantab.net>
Backport #24487 by @fnetX
On the @Forgejo instance of Codeberg, we discovered that forking a repo
which is already forked now returns a 500 Internal Server Error, which
is unexpected. This is an attempt at fixing this.
The error message in the log:
~~~
2023/05/02 08:36:30 .../api/v1/repo/fork.go:147:CreateFork() [E]
[6450cb8e-113] ForkRepository: repository is already forked by user
[uname: ...., repo path: .../..., fork path: .../...]
~~~
The service that is used for forking returns a custom error message
which is not checked against.
About the order of options:
The case that the fork already exists should be more common, followed by
the case that a repo with the same name already exists for other
reasons. The case that the global repo limit is hit is probably not the
likeliest.
---------
Co-authored-by: Otto Richter (fnetX) <git@fralix.ovh>
Backport #24382 by @lunny
Fix https://github.com/go-gitea/gitea/pull/24362/files#r1179095324
`getAuthenticatedMeta` has checked them, these code are duplicated one.
And the first invokation has a wrong permission check. `DownloadHandle`
should require read permission but not write.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #24362 by @jolheiser
> The scoped token PR just checked all API routes but in fact, some web
routes like `LFS`, git `HTTP`, container, and attachments supports basic
auth. This PR added scoped token check for them.
Signed-off-by: jolheiser <john.olheiser@gmail.com>
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #24339 by @yardenshoham
I made it render the script even if the repo is archived
- Fixes#24324
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: Yarden Shoham <git@yardenshoham.com>
Backport #24307Fix#24305
According to MDN, "bold" starts from 700, some fonts do not provide
"bolding" for weight 600
Manually backport, no CSS conflict.
Backport #24035 by @garymoon
This change prevents Gitea from bypassing the manual approval process
for newly registered users when OIDC is used.
- Resolves https://github.com/go-gitea/gitea/issues/23392
Signed-off-by: Gary Moon <gary@garymoon.net>
Co-authored-by: Gary Moon <garymoon@users.noreply.github.com>
Backport #24116 by @techknowlogick
Proposal found here: https://github.com/go-gitea/gitea/issues/23654
TODO: make non-breaking (can we publish docker image using dev and
nightly prefix? at same time). if anyone has advice please comment :)
If this PR is merged, then I can add redirects to the downloads site.
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
