Backport #26087 by @KN4CK3R
Fixes #26022
- Fix handling of files with trailing slash
- Fix handling of duplicate package file errors
- Added test for both
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit a424f6d4f8)
Backport #26074 by @wxiaoguang
If the log file can't be opened, what should it do? panic/exit? ignore
logs? fallback to stderr?
It seems that "fallback to stderr" is slightly better than others ....
(cherry picked from commit 8d9193680d)
Backport #26001 by @wxiaoguang
Regression of #24832
Fix the bug and add a test for it
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 4d5e3b9372)
Backport #25417 by @wxiaoguang
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: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit ee47face12)
Backport #25944
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
(cherry picked from commit 5c3662b902)
Regression: https://github.com/go-gitea/gitea/pull/24805
Closes: #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>
(cherry picked from commit ab54310731)
Backport #25919 by @wxiaoguang
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.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 9369b38315)
It breaks existing instances that would otherwise work perfectly
fine. Failing to start an instance should only happen when there is a
compelling reason to do so, for instance if the `app.ini` could not be
modified in a way that is backward compatible. If the only motivation
is to remove the setting for cosmetic reason, it must not be fatal.
(cherry picked from commit c09ef82e9a)
(cherry picked from commit e80aaa11d9)
Backport #25920 by @KN4CK3R
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.
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 6e82d0bb7c)
It breaks existing instances that would otherwise work perfectly
fine. Failing to start an instance should only happen when there is a
compelling reason to do so, for instance if the `app.ini` could not be
modified in a way that is backward compatible. If the only motivation
is to remove the setting for cosmetic reason, it must not be fatal.
(cherry picked from commit c09ef82e9a)
- The library that's being used for org-mode, [doesn't render the status
of list items](https://github.com/niklasfasching/go-org/issues/63).
- Add a modified version of the proposed CSS snippet to still display
the status for the list items. The alternative was parsing HTML and
transforming it, which is too complicated for this small task.
- Resolves https://codeberg.org/Codeberg/Community/issues/1099
- Follow up for: #540, #802
- Add API routes for user blocking from user and organization
perspective.
- The new routes have integration testing.
- The new model functions have unit tests.
- Actually quite boring to write and to read this pull request.
(cherry picked from commit f3afaf15c7)
(cherry picked from commit 6d754db3e5)
(cherry picked from commit d0fc8bc9d3)
(cherry picked from commit 9a53b0d1a0)
(cherry picked from commit 44a2a4fd48)
(cherry picked from commit 182025db9c)
(cherry picked from commit 558a35963e)
FORGEJO_* environment variables are set to the corresponding GITEA_*
variable when the cli starts. This approach is intended to minimize
the conflicts on rebase. All occurences of GITEA_* are left untouched
in the codebase and they are only changed to FORGEJO_* if exposed to
the user.
(cherry picked from commit e466f9d10e)
(cherry picked from commit e33e95931b)
(cherry picked from commit 2cfc6519b7)
(cherry picked from commit af8864373a)
(cherry picked from commit a0550ff339)
(cherry picked from commit 24dc0a5191)
(cherry picked from commit e255eea2b4)
(cherry picked from commit 0c4f5afa7a)
(cherry picked from commit 42fce708d0)
(cherry picked from commit e7278c3c22)
(cherry picked from commit 0fb9ed7e0e)
(cherry picked from commit a98308aa4d)
(cherry picked from commit b8695fcbe0)
(cherry picked from commit 4aee8719f5)
(cherry picked from commit 1c503c1ba7)
(cherry picked from commit cf1ed8551e)
(cherry picked from commit c52459b088)
(cherry picked from commit 92cac277b2)
(cherry picked from commit 2c744f1118)
(cherry picked from commit 1482cfabe5)
Replaces `Gitea` with `Forgejo` in the default config settings for new installs.
This will not affect existing installs.
Co-authored-by: Caesar Schinas <caesar@caesarschinas.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/140
Co-authored-by: Caesar Schinas <caesar@noreply.codeberg.org>
Co-committed-by: Caesar Schinas <caesar@noreply.codeberg.org>
(cherry picked from commit ca1319aa16)
(cherry picked from commit 52a4d238a0)
(cherry picked from commit f63536538c)
Conflicts:
web_src/js/features/install.js
(cherry picked from commit 861cc434e1)
(cherry picked from commit 0e6ea60c80)
(cherry picked from commit 0cbc0ec15d)
(cherry picked from commit 3cc19b0ae2)
(cherry picked from commit 50fcb885fe)
(cherry picked from commit f6039d4df4)
(cherry picked from commit 5ae5c6ba2d)
(cherry picked from commit f0b565e0ed)
(cherry picked from commit adbd4d2015)
(cherry picked from commit d26c540ffd)
(cherry picked from commit 6df6781b42)
(cherry picked from commit b6fb56e1c4)
(cherry picked from commit bb4f98a0ca)
(cherry picked from commit 6779229f27)
(cherry picked from commit d6e878a739)
(cherry picked from commit b3c612f2ab)
(cherry picked from commit ab09b75301)
(cherry picked from commit 4bd4279a96)
(cherry picked from commit 1882439f8d)
- Use TXT records in order to determine the latest available version.
- This addresses a valid privacy issue, as with HTTP requests the server
can keep track(estimated) of how many instances are using Forgejo, with
DNS that's basically not possible as the server will never receive any
data, as the only ones receiving data are DNS resolvers.
(cherry picked from commit 0baefb546a)
(cherry picked from commit e8ee41880b)
(cherry picked from commit 7eca4f3bf1)
(cherry picked from commit 6dde3992dc)
(cherry picked from commit fb3a37fbfc)
(cherry picked from commit 8304af1e9d)
(cherry picked from commit 0543a7d12a)
(cherry picked from commit c3a22933b7)
(cherry picked from commit e243707694)
(cherry picked from commit 7eb6d1bcf7)
(cherry picked from commit 1d7b9535cd)
(cherry picked from commit 05920dce67)
(cherry picked from commit f173f27d7c)
(cherry picked from commit 90e1c9340e)
(cherry picked from commit de68610ea7)
(cherry picked from commit 8d5757ea04)
(cherry picked from commit c7a7fff316)
(cherry picked from commit 39ac8b8fc1)
(cherry picked from commit 2f65c02905)
(cherry picked from commit 74b5133374)
(cherry picked from commit e31c34e893)
Backport #25746
Fix #25736
Caused by #24048
Right now we only check the activity type for `pull_request` event when
`types` is specified or there are no `types` and filter. If a workflow
only specifies filters but no `types` like this:
```
on:
pull_request:
branches: [main]
```
the workflow will be triggered even if the activity type is not one of
`[opened, reopened, sync]`. We need to check the activity type in this
case.
Backport #25648
Replace #25580
Fix #19453
The problem was: when users set "GITEA__XXX__YYY" , the "install page"
doesn't respect it.
So, to make the result consistent and avoid surprising end users, now
the "install page" also writes the environment variables to the config
file.
And, to make things clear, there are enough messages on the UI to tell
users what will happen.
There are some necessary/related changes to `environment-to-ini.go`:
* The "--clear" flag is removed and it was incorrectly written there.
The "clear" operation should be done if INSTALL_LOCK=true
* The "--prefix" flag is removed because it's never used, never
documented and it only causes inconsistent behavior.
The only conflict during backport is "ui divider" in
templates/install.tmpl
Backport #25707 by @KN4CK3R
Fixes (?) #25538
Fixes https://codeberg.org/forgejo/forgejo/issues/972
Regression #23879#23879 introduced a change which prevents read access to packages if a
user is not a member of an organization.
That PR also contained a change which disallows package access if the
team unit is configured with "no access" for packages. I don't think
this change makes sense (at the moment). It may be relevant for private
orgs. But for public or limited orgs that's useless because an
unauthorized user would have more access rights than the team member.
This PR restores the old behaviour "If a user has read access for an
owner, they can read packages".
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
Backport #25581 by @wolfogre
Resolve #24789
## ⚠️ BREAKING ⚠️
Before this, `DEFAULT_ACTIONS_URL` cound be set to any custom URLs like
`https://gitea.com` or `http://your-git-server,https://gitea.com`, and
the default value was `https://gitea.com`.
But now, `DEFAULT_ACTIONS_URL` supports only
`github`(`https://github.com`) or `self`(the root url of current Gitea
instance), and the default value is `github`.
If it has configured with a URL, an error log will be displayed and it
will fallback to `github`.
Actually, what we really want to do is always make it
`https://github.com`, however, this may not be acceptable for some
instances of internal use, so there's extra support for `self`, but no
more, even `https://gitea.com`.
Please note that `uses: https://xxx/yyy/zzz` always works and it does
exactly what it is supposed to do.
Although it's breaking, I belive it should be backported to `v1.20` due
to some security issues.
Follow-up on the runner side:
- https://gitea.com/gitea/act_runner/pulls/262
- https://gitea.com/gitea/act/pulls/70
Co-authored-by: Jason Song <i@wolfogre.com>
Backport #25560 by @wolfogre
Fix #25451.
Bugfixes:
- When stopping the zombie or endless tasks, set `LogInStorage` to true
after transferring the file to storage. It was missing, it could write
to a nonexistent file in DBFS because `LogInStorage` was false.
- Always update `ActionTask.Updated` when there's a new state reported
by the runner, even if there's no change. This is to avoid the task
being judged as a zombie task.
Enhancement:
- Support `Stat()` for DBFS file.
- `WriteLogs` refuses to write if it could result in content holes.
Co-authored-by: Jason Song <i@wolfogre.com>
Backport #25537
More fix for #24981
* #24981
Close #22361, #25552
* #22361
* #25552
There were many patches for Gitea's sub-commands to satisfy the facts:
* Some sub-commands shouldn't output any log, otherwise the git protocol
would be broken
* Sometimes the users want to see "verbose" or "quiet" outputs
That's a longstanding problem, and very fragile. This PR is only a quick
patch for the problem.
In the future, the sub-command system should be refactored to a clear
solution.
----
Other changes:
* Use `ReplaceAllWriters` to replace
`RemoveAllWriters().AddWriters(writer)`, then it's an atomic operation.
* Remove unnecessary `syncLevelInternal` calls, because
`AddWriters/addWritersInternal` already calls it.
Backport #25480 by @wxiaoguang
Fix #25481
The `InitWorkPathAndCommonConfig` calls `LoadCommonSettings` which does
many checks like "current user is root or not".
Some commands like "environment-to-ini" shouldn't do such check, because
it might be run with "root" user at the moment (eg: the docker's setup
script)
ps: in the future, the docker's setup script should be improved to avoid
Gitea's command running with "root"
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #25330
# The problem
There were many "path tricks":
* By default, Gitea uses its program directory as its work path
* Gitea tries to use the "work path" to guess its "custom path" and
"custom conf (app.ini)"
* Users might want to use other directories as work path
* The non-default work path should be passed to Gitea by GITEA_WORK_DIR
or "--work-path"
* But some Gitea processes are started without these values
* The "serv" process started by OpenSSH server
* The CLI sub-commands started by site admin
* The paths are guessed by SetCustomPathAndConf again and again
* The default values of "work path / custom path / custom conf" can be
changed when compiling
# The solution
* Use `InitWorkPathAndCommonConfig` to handle these path tricks, and use
test code to cover its behaviors.
* When Gitea's web server runs, write the WORK_PATH to "app.ini", this
value must be the most correct one, because if this value is not right,
users would find that the web UI doesn't work and then they should be
able to fix it.
* Then all other sub-commands can use the WORK_PATH in app.ini to
initialize their paths.
* By the way, when Gitea starts for git protocol, it shouldn't output
any log, otherwise the git protocol gets broken and client blocks
forever.
The "work path" priority is: WORK_PATH in app.ini > cmd arg --work-path
> env var GITEA_WORK_DIR > builtin default
The "app.ini" searching order is: cmd arg --config > cmd arg "work path
/ custom path" > env var "work path / custom path" > builtin default
## ⚠️ BREAKING
If your instance's "work path / custom path / custom conf" doesn't meet
the requirements (eg: work path must be absolute), Gitea will report a
fatal error and exit. You need to set these values according to the
error log.
