Update WorkPath/WORK_PATH related documents, remove out-dated
information.
Remove "StaticRootPath" on the admin config display page, because few
end user really need it, it only causes misconfiguration.
Co-authored-by: Giteabot <teabot@gitea.io>
Since OAuth2 will callback the root URL, if the user starts signing in
from a wrong host, Gitea will return 500 because it cannot find the
session.
<details>
<summary>How to reproduce</summary>
<img width="901" alt="image"
src="2c2e255c-e13e-4a11-9be7-b226bee54920">
<img width="1014" alt="image"
src="b31cfcf6-a320-483d-9ce5-ba8562f065e1">
</details>
So show the mismatched ROOT_URL warning on the sign-in page if OAuth2 is
enabled.
<img width="1015" alt="image"
src="99e80b17-c790-49a3-bbf2-2bd9396a7daa">
Before: the concept "Content string" is used everywhere. It has some
problems:
1. Sometimes it means "base64 encoded content", sometimes it means "raw
binary content"
2. It doesn't work with large files, eg: uploading a 1G LFS file would
make Gitea process OOM
This PR does the refactoring: use "ContentReader" / "ContentBase64"
instead of "Content"
This PR is not breaking because the key in API JSON is still "content":
`` ContentBase64 string `json:"content"` ``
With the introduction of Actions, the pending commit icon has changed
from yellow to grey for Drone integrations which never set the "running"
status, so it stays in "pending" until completion.
I find it better to have this icon colored like on 1.19. Now both the
"pending" and "running" icons look the same, but I guess we could add an
animation to the "running" state similar to GitHub has to it later.
Before:
<img width="339" alt="Screenshot 2023-07-17 at 19 14 19"
src="2f4886e4-74fd-42ea-b59e-9af8f141bf1f">
After:
<img width="335" alt="Screenshot 2023-07-17 at 19 14 30"
src="53189642-e72d-47f6-9cbe-f14eda28f730">
Also, it matches GH's icon:
<img width="466" alt="image"
src="5804ff90-d223-4a3c-8093-7a9abbaacf87">
---------
Co-authored-by: delvh <dev.lh@web.de>
Move `public/*` to `public/assets/*`
Some old PRs (like #15219) introduced inconsistent directory system.
For example: why the local directory "public" is accessed by
`http://site/assets`? How to serve the ".well-known" files properly in
the public directory?
For convention rules, the "public" directory is widely used for the
website's root directory. It shouldn't be an exception for Gitea.
So, this PR makes the things consistent:
* `http://site/assets/foo` means `{CustomPath}/public/assets/foo`.
* `{CustomPath}/public/.well-known` and `{CustomPath}/public/robots.txt`
can be used in the future.
This PR is also a prerequisite for a clear solution for:
* #21942
* #25892
* discourse.gitea.io: [.well-known path serving custom files behind
proxy?](https://discourse.gitea.io/t/well-known-path-serving-custom-files-behind-proxy/5445/1)
This PR is breaking for users who have custom "public" files (CSS/JS).
After getting approvals, I will update the documents.
----
## ⚠️ BREAKING ⚠️
If you have files in your "custom/public/" folder, please move them to
"custom/public/assets/".
---------
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Giteabot <teabot@gitea.io>
Regression: https://github.com/go-gitea/gitea/pull/24805Closes: #25945
- Disallow `javascript`, `vbscript` and `data` (data uri images still
work) url schemes even if all other schemes are allowed
- Fixed older `cbthunderlink` tests
---------
Co-authored-by: delvh <dev.lh@web.de>
The "creating dir/file during load config" is a longstanding and complex
problem.
This PR only does a quick patch, it still needs more refactorings in the
future.
Fix#25938
Previously, `sortablejs` was imported twice, once synchronously and once
asynchronously, leading to webpack creating duplicate output code (once
in the index bundle, and once in a separate chunk). Fix this by always
asynchronously importing it. This was one of the build warnings observed
when trying to build with vite.
Before, in dev mode, there might be some error logs like:
```
2023/07/17 13:54:51 ...s/assetfs/layered.go:221:WatchLocalChanges() [E] Unable to watch directory .: lstat /data/work/gitea/custom/templates: no such file or directory
```
Because there is no "custom/templates" directory.
After: ignore such error, no such error message anymore.
Got the same problem as #25915 when updating an instance. The
`log.Fatal` should have been marked as breaking in #23911.
This PR adds a notice that the system is shutting down because of the
deprecated setting.
We can select PRs to open/close them by one click, but we forgot to
check whether it is merged.
You can get an opening merged PR:
You can confirm this in:
https://try.gitea.io/yp05327/testrepo/pulls/5
Use a real button and add an aria-label.
Additionally, show the button whenever it is focused.
See https://codeberg.org/forgejo/forgejo/issues/998 for explanation.
Our handling of this button is now equal to that of GitHub.
Nothing has changed visually.
Before: (Owner list is empty)
After: (Disable the button and show the error info)
Before:
emmm, don't know how to write a good title to describe this issue.
If you have a good idea, I can change the title.
The fix code is copied from L122. Not sure it is right or not.
@lunny
Maybe `DefaultBranchBranch` is also typo?
Two `Branch` in variable name .
When only the case of the username changes and the new username is
consistent with the lowercase username of the old user name, update the
owner name of the repo, and keep the original logic consistent with
other conditions.
example: your username is `gitea`, lowercase username is `gitea`,repo
url is `.../gitea/{repo}`, you changed username to `Gitea` or `GiTea` or
other, but the lowercase username is still `gitea`, the repo url is
still `.../gitea/{repo}`.
this pr fixed it,keep username and repo url consistent.
Before:
After:
the stacking takes up screen space - display the tabs as the navigation
bar. github uses the same layout.
Screenshots (left before, right after):
Large screen:
Issue filters are being used on repo list page and on milestone issues
page, and the code is mostly duplicated.
This PR does the following changes:
- move issue filters into a shared template
- allow filtering milestone issues by project, so no need to hide this
filter on milestone issues page
- remove some dead code (e. g. issue actions in milestone issues
template)
- fix label filter dropdown width
---------
Co-authored-by: 6543 <6543@obermui.de>
The `FileBlame` function looks strange, it has `revision` as argument
but doesn't use it.
Since the function never be used, I think we could just remove it.
If anyone thinks it should be kept, please help fix `revision`.
Co-authored-by: Giteabot <teabot@gitea.io>
Before:
After:
This issue comes from the change in #25468.
`LoadProject` will always return at least one record, so we use
`ProjectID` to check whether an issue is linked to a project in the old
code.
As other `issue.LoadXXX` functions, we need to check the return value
from `xorm.Session.Get`.
In recent unit tests, we only test `issueList.LoadAttributes()` but
don't test `issue.LoadAttributes()`. So I added a new test for
`issue.LoadAttributes()` in this PR.
---------
Co-authored-by: Denys Konovalov <privat@denyskon.de>
Related issue: #18368
It doesn't seem right to "guess" the file encoding/BOM when using API to
upload files.
The API should save the uploaded content as-is.
we refactored `userIDFromToken` for the token parsing part into a new
function `parseToken`. `parseToken` returns the string `token` from
request, and a boolean `ok` representing whether the token exists or
not. So we can distinguish between token non-existence and token
inconsistency in the `verfity` function, thus solving the problem of no
proper error message when the token is inconsistent.
close#24439
related #22119
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: Giteabot <teabot@gitea.io>
Fix#25726#17846 chose an incorrect WORK_DIR path for docker root image.
Gitea's work-path was already used as the base path for various paths
(like AppDataPath), so, the work-path should be mounted to a volume in a
docker image.
Now, for docker root image, it's unavoidable to mix the
WorkPath/CustomPath/AppDataPath in the same directory ("/data/gitea"),
because some of them have already been mixed.
Some directories in the screenshot are for "CustomPath" , while others
are for "AppDataPath", due to the technical debts in old code:
```
CUSTOM_PATH="/data/gitea"
APP_DATA_PATH = /data/gitea
```
<details>
</details>
This PR is breaking but this is the only way at the moment to avoid
users losing their data accidently
Co-authored-by: Giteabot <teabot@gitea.io>
All 3 tabs of the PR (Conversation, Commits and Files changed) should
show the edit title button.
Before this commit the edit button was not shown on commits tab
Screenshots:
After:
Before:
Just for reference the edit button in files changed tab:
Co-authored-by: Giteabot <teabot@gitea.io>
