Backport #24925, partially backport #24934
(`docs/content/doc/help/faq.zh-cn.md` file)
Part of backport has already done by #24942
Also backport #24881 to avoid "deadlock"
---------
Co-authored-by: Zettat123 <zettat123@gmail.com>
Backport #24979
Changes:
1. Use uniform links types relative to doc folder (start with `doc/`)
2. According to [docusaurus
links](https://docusaurus.io/docs/markdown-features/links), if `<a>` is
used, the `href` is resolved as URL location, but not file location. So
need to use `[text]({{< relref "path" >}})` instead.
replace #24868
just a patch to fix#24824 in v1.19.4
The reference name of commits when synchronizing should also has prefix
like refs/heads/<branch-name>.
Backport #24900Fix#24896
If users set different languages by `linguist-language`, the `stats` map
could be: `java: 100, Java: 200`.
Language stats are stored as case-insensitive in database and there is a
unique key.
So, the different language names should be merged to one unique name:
`Java: 300`
`Secrets` options should be hidden if `Actions` feature is disabled.
This fixes in release/v1.19. In main probably fixed in
63a401ac40ce2cc19c7d0341d11d434b568653fc (didn't check).
Fixes: 659055138b6d32492b20c9f4d1d5a3cdaa47188d
Author-Change-Id: IB#1134011
Signed-off-by: Pawel Boguslawski <pawel.boguslawski@ib.pl>
Backport #24825 by @yardenshoham
The topics are saved in the repo_topic table with a repoID key. They are
also saved directly in the repository table.
Before this PR, only `AddTopic` and `SaveTopics` made sure the `topics`
field in the repository field was synced with the repo_topic table.
This PR makes sure `GenerateTopics` and `DeleteTopic` also sync the
`topics` in the repository table.
`RemoveTopicsFromRepo` doesn't need to sync the data as it is only used
to delete a repository.
- Fixes#24820
Backport #24802 by @wolfogre
Regression of #24536. If the user doesn't explicitly disable Actions, it
will be enabled.
1. Gitea will call `loadRepositoryFrom` before `loadActionsFrom`.
25d4f95df2/modules/setting/setting.go (L234-L237)
2. In `loadRepositoryFrom`,
`rootCfg.Section("actions").Key("ENABLED").MustBool(true)` will set
`actions.ENABLED` with `true`.
25d4f95df2/modules/setting/repository.go (L313-L315)
3. In `loadActionsFrom`, `rootCfg.Section("actions")` will get a section
with Actions enabled.
25d4f95df2/modules/setting/actions.go (L23-L26)
Although the cause of the problem was using `true` by copy-paste
mistake, it also surprised me that
**`rootCfg.Section("actions").Key("ENABLED").MustBool(true)` doesn't
only read, but also write.**
Co-authored-by: Jason Song <i@wolfogre.com>
Backport #24751 by @wxiaoguang
Make mailer SMTP check have timed context
Otherwise Gitea may block for long time if the DNS request blocks.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #24470Fixes#24145
---
To solve the bug, I added a "computed" `TargetBehind` field to the
`Release` model, which indicates the target branch of a release. This is
particularly useful if the target branch was deleted in the meantime (or
is empty).
I also did a micro-optimization in `calReleaseNumCommitsBehind`. Instead
of checking that a branch exists and then call `GetBranchCommit`, I
immediately call `GetBranchCommit` and handle the `git.ErrNotExist`
error.
This optimization is covered by the added unit test.
_contributed in the context of @forgejo_
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>
