Giteabot [Mon, 5 Jun 2023 15:05:52 +0000 (11:05 -0400)]
Fix parallelly generating index failure with Mysql (#24567) (#25081)
Backport #24567 by @lunny
- Fix possible parallel creating commit status index problem and
creating issues/pull request index problem work with Mysql5/Mysql8
- Add parallel tests
- Reenable TestRepoCommitsStatusParallel on CI
HesterG [Tue, 30 May 2023 10:08:32 +0000 (18:08 +0800)]
Unify doc links to use paths relative to doc folder (#24979) (#25000)
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.
sillyguodong [Tue, 30 May 2023 05:12:21 +0000 (13:12 +0800)]
Fix missing reference prefix of commits when sync mirror repository (#24994)
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>.
Giteabot [Fri, 19 May 2023 13:17:48 +0000 (09:17 -0400)]
Fix Actions being enabled accidentally (#24802) (#24810)
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`.
https://github.com/go-gitea/gitea/blob/25d4f95df25dae5226e96e813dde87b071d9155e/modules/setting/setting.go#L234-L237
2. In `loadRepositoryFrom`,
`rootCfg.Section("actions").Key("ENABLED").MustBool(true)` will set
`actions.ENABLED` with `true`.
https://github.com/go-gitea/gitea/blob/25d4f95df25dae5226e96e813dde87b071d9155e/modules/setting/repository.go#L313-L315
3. In `loadActionsFrom`, `rootCfg.Section("actions")` will get a section
with Actions enabled.
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.**
oliverpool [Fri, 12 May 2023 18:14:41 +0000 (20:14 +0200)]
fix: release page for empty or non-existing target (#24659)
Backport #24470
Fixes #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.
Giteabot [Mon, 8 May 2023 10:48:06 +0000 (06:48 -0400)]
Refresh the refernce of the closed PR when reopening (#24231) (#24587)
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](https://github.com/go-gitea/gitea/blob/74225033413dc0f2b308bbe069f6d185b551e364/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`.
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.
Giteabot [Fri, 5 May 2023 13:07:02 +0000 (09:07 -0400)]
Fix the permission of team's `Actions` unit issue (#24536) (#24545)
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.
Giteabot [Wed, 3 May 2023 12:15:56 +0000 (08:15 -0400)]
Fix api error message if fork exists (#24487) (#24493)
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>
Giteabot [Tue, 2 May 2023 20:58:11 +0000 (16:58 -0400)]
Enable whitespace rendering on selection in Monaco (#24444) (#24485)
Backport #24444 by @silverwind
Remove the
[renderWhitespace](https://microsoft.github.io/monaco-editor/docs.html#interfaces/editor.IEditorOptions.html#renderWhitespace)
override, so the default value of `selection` takes over and makes
whitespace visible on selection.
<img width="128" alt="Screenshot 2023-04-30 at 19 09 41"
src="https://user-images.githubusercontent.com/115237/235366707-d598268d-03cc-4839-a195-c460bddae99b.png">
`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.
Add tags list for repos whose release setting is disabled (#23465) (#24369)
Backport #23465
Close #23427
Co-Author: @wxiaoguang
If a repo's release setting is enabled, the logic has't changed.
Clicking the "Tags" button will jump to `/{user}/{repo}/tags` and
`templates/repo/release/list.tmpl` template will be used.
If the release setting is disabled, clicking the "Tags" button will
still jump to `/{user}/{repo}/tags` but a new template
`templates/repo/tag/list.tmpl` will be used.
Require repo scope for PATs for private repos and basic authentication (#24362) (#24364)
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.
Fix https://github.com/go-gitea/gitea/issues/16188. Turns out the
element was completely misaligned by fomantic styles. Add most of the
original styles in `!important` form to fix.
Tapping the button doesn't do anything useful in Simulator.app, but I
guess it's still better to not outright hide it in case it has a
possiblity to work.
Don't set meta `theme-color` by default (#24340) (#24346)
Backport #24340 by @silverwind
Fixes https://github.com/go-gitea/gitea/issues/24321. By not setting
this meta tag, Safari will use body color for chrome and out-of-viewport
areas, which looks much better then static mismatching green.
As per
[MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name/theme-color)
it's really only Apple browsers who still support this tag, most others
have dropped support.
Before:
<img width="347" alt="Screenshot 2023-04-25 at 19 59 13"
src="https://user-images.githubusercontent.com/115237/234363180-0fe667ef-5469-4f5f-b31a-c9d73aff10ac.png">
After:
<img width="361" alt="Screenshot 2023-04-25 at 20 00 00"
src="https://user-images.githubusercontent.com/115237/234363185-e2d2b62f-0133-4316-944d-b614ffb84eb0.png">
- Support `configuration variables`
([#43](https://gitea.com/gitea/act/pulls/43))
- Support specifying command for `services` containers
([#50](https://gitea.com/gitea/act/pulls/50))
Fix label color, fix divider in dropdown (#24215) (#24244)
Backport #24215 by @silverwind
Two small CSS fixes:
1. Fix basic primary label hover:
Before:
<img width="172" alt="Screenshot 2023-04-19 at 20 00 32"
src="https://user-images.githubusercontent.com/115237/233161903-eec2de54-1a58-44ac-a6ef-2d77157317f6.png">
After:
<img width="179" alt="Screenshot 2023-04-19 at 20 05 29"
src="https://user-images.githubusercontent.com/115237/233162028-995404ac-5852-4d03-821f-6eb4a918a9e3.png">
2. Fix border color of divider in dropdown and remove margin so it looks
better with hover effect, as discussed in
https://github.com/go-gitea/gitea/pull/24143:
<img width="205" alt="Screenshot 2023-04-19 at 20 03 24"
src="https://user-images.githubusercontent.com/115237/233162102-3f4a4142-9634-4c95-acf0-be57072ce7eb.png">
<img width="311" alt="Screenshot 2023-04-19 at 20 03 55"
src="https://user-images.githubusercontent.com/115237/233162109-faa616f6-02e4-43d3-95fa-66787a7f914c.png">
Vertical widths of containers removed (#24184) (#24211)
Backport #24184 by @krzysztofjeziorny
A vertical overflow appears in Firefox 112/MacOS 12.6 when the system
setting for scrollbars is to "Always" show them.
Here, the fixed 100vw container widths are removed, which removes the
overflow. It is, however, only simulated in Developer Tools in latest
Firefox and Chromium, so please test on a Gitea installation.
Co-authored-by: Krzysztof Jeziorny <872730+krzysztofjeziorny@users.noreply.github.com>
* The renaming detection is wrong (eg: pasting a new name into the input
doesn't trigger the detection)
* The renaming prompt layout is not good
* Some MaxSize/maxlength rules is missing
Support converting varchar to nvarchar for mssql database (#24105) (#24168)
Backport #24105 by @lunny
In #12269, all string fields of struct will generate a NVARCHAR column
in database, but for those Gitea instances installed before that PR,
users have to convert columns themselves.
In this PR, we update the `./gitea admin convert` commands to support
both MySQL and MSSQL database converting. Previously, it only supported
converting `utf8 -> utf8mb4` for MySQL.
Now, it will check the database types.
If it's MSSQL, it will convert `VARCHAR -> NVARCHAR` as well.
projects / gitea.git / log