summaryrefslogtreecommitdiffstats
path: root/modules/setting
Commit message (Collapse)AuthorAgeFilesLines
* Make "install page" respect environment config (#25648) (#25799)wxiaoguang2023-07-105-9/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Replace `interface{}` with `any` (#25686) (#25687)silverwind2023-07-042-3/+3
| | | | Same perl replacement as https://github.com/go-gitea/gitea/pull/25686 but for 1.20 to ease future backporting.
* Restrict `[actions].DEFAULT_ACTIONS_URL` to only `github` or `self` (#25581) ↵Giteabot2023-06-302-2/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#25604) Backport #25581 by @wolfogre Resolve #24789 ## :warning: BREAKING :warning: 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>
* Do not prepare oauth2 config if it is not enabled, do not write config in ↵wxiaoguang2023-06-291-0/+4
| | | | | | | | | | | | some sub-commands (#25567) (#25576) Backport #25567 Ref: * https://github.com/go-gitea/gitea/issues/25377#issuecomment-1609757289 And some sub-commands like "generate" / "docs", they do not need to use the ini config
* Fix sub-command log level (#25537) (#25553)wxiaoguang2023-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use InitWorkPathAndCfgProvider for environment-to-ini to avoid unnecessary ↵v1.20.0-rc2Giteabot2023-06-241-2/+6
| | | | | | | | | | | | | | | | | | | checks (#25480) (#25488) 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>
* Refactor path & config system (#25330) (#25416)wxiaoguang2023-06-226-168/+398
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use "utf8mb4" for MySQL by default (#25432)wxiaoguang2023-06-221-15/+11
| | | | | | TBH, I don't see much difference from `Remove "CHARSET" config option for MySQL, always use "utf8mb4"` #25413 Close #25413
* Avoid polluting config file when "save" (#25395) (#25406)Giteabot2023-06-216-13/+85
| | | | | | | | | | | | | | | | | Backport #25395 by @wxiaoguang That's a longstanding INI package problem: the "MustXxx" calls change the option values, and the following "Save" will save a lot of garbage options into the user's config file. Ideally we should refactor the INI package to a clear solution, but it's a huge work. A clear workaround is what this PR does: when "Save", load a clear INI instance and save it. Partially fix #25377, the "install" page needs more fine tunes. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Avoid polluting the config (#25345) (#25354)Giteabot2023-06-183-14/+16
| | | | | | | Backport #25345 by @wxiaoguang Caught by #25330 Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Fix all possible setting error related storages and added some tests ↵Giteabot2023-06-1416-291/+946
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (#23911) (#25244) Backport #23911 by @lunny Follow up #22405 Fix #20703 This PR rewrites storage configuration read sequences with some breaks and tests. It becomes more strict than before and also fixed some inherit problems. - Move storage's MinioConfig struct into setting, so after the configuration loading, the values will be stored into the struct but not still on some section. - All storages configurations should be stored on one section, configuration items cannot be overrided by multiple sections. The prioioty of configuration is `[attachment]` > `[storage.attachments]` | `[storage.customized]` > `[storage]` > `default` - For extra override configuration items, currently are `SERVE_DIRECT`, `MINIO_BASE_PATH`, `MINIO_BUCKET`, which could be configured in another section. The prioioty of the override configuration is `[attachment]` > `[storage.attachments]` > `default`. - Add more tests for storages configurations. - Update the storage documentations. Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Refactor INI package (first step) (#25024)wxiaoguang2023-06-025-59/+205
| | | | | | | | | The INI package has many bugs and quirks, and in fact it is unmaintained. This PR is the first step for the INI package refactoring: * Use Gitea's "config_provider" to provide INI access * Deprecate the INI package by golangci.yml rule
* Remove the service worker (#25010)silverwind2023-05-311-2/+0
| | | | | | | | | | | | | It's been disabled by default since 1.17 (https://github.com/go-gitea/gitea/pull/18914), and it never really delivered any benefit except being another cache layer that has its own unsolved invalidation issues. HTTP cache works, we don't need two cache layers at the browser for assets. ## :warning: BREAKING You can remove the config `[ui].USE_SERVICE_WORKER` from your `app.ini` now.
* Remove meta tags `theme-color` and `default-theme` (#24960)silverwind2023-05-281-2/+0
| | | | | | | | | | | | | | | | As discussed in https://github.com/go-gitea/gitea/pull/24953#issuecomment-1565630156. ## :warning: BREAKING :warning: 1. The `ui.THEME_COLOR_META_TAG` setting has been removed. If you still need to set the `theme-color` meta tag, add it via `$GITEA_CUSTOM/templates/custom/header.tmpl` instead. 2. The non-standard `default-theme` meta-tag added in https://github.com/go-gitea/gitea/pull/13809 has been removed. Third party code that needs to obtain the currently loaded theme should use the `theme-<name>` class on the `<html>` node instead, which reflect the currently active theme.
* Use `[git.config]` for reflog cleaning up (#24958)wxiaoguang2023-05-282-23/+58
| | | | | | | | | | | | | | | | | | | Follow https://github.com/go-gitea/gitea/pull/24860#discussion_r1200589651 Use `[git.config]` for reflog cleaning up, the new options are more flexible. * https://git-scm.com/docs/git-config#Documentation/git-config.txt-corelogAllRefUpdates * https://git-scm.com/docs/git-config#Documentation/git-config.txt-gcreflogExpire ## :warning: BREAKING The section `[git.reflog]` is now obsolete and its keys have been moved to the following replacements: - `[git.reflog].ENABLED` → `[git.config].core.logAllRefUpdates` - `[git.reflog].EXPIRATION` → `[git.config].gc.reflogExpire`
* Add the ability to pin Issues (#24406)JakobDev2023-05-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the ability to pin important Issues and Pull Requests. You can also move pinned Issues around to change their Position. Resolves #2175. ## Screenshots ![grafik](https://user-images.githubusercontent.com/15185051/235123207-0aa39869-bb48-45c3-abe2-ba1e836046ec.png) ![grafik](https://user-images.githubusercontent.com/15185051/235123297-152a16ea-a857-451d-9a42-61f2cd54dd75.png) ![grafik](https://user-images.githubusercontent.com/15185051/235640782-cbfe25ec-6254-479a-a3de-133e585d7a2d.png) The Design was mostly copied from the Projects Board. ## Implementation This uses a new `pin_order` Column in the `issue` table. If the value is set to 0, the Issue is not pinned. If it's set to a bigger value, the value is the Position. 1 means it's the first pinned Issue, 2 means it's the second one etc. This is dived into Issues and Pull requests for each Repo. ## TODO - [x] You can currently pin as many Issues as you want. Maybe we should add a Limit, which is configurable. GitHub uses 3, but I prefer 6, as this is better for bigger Projects, but I'm open for suggestions. - [x] Pin and Unpin events need to be added to the Issue history. - [x] Tests - [x] Migration **The feature itself is currently fully working, so tester who may find weird edge cases are very welcome!** --------- Co-authored-by: silverwind <me@silverwind.io> Co-authored-by: Giteabot <teabot@gitea.io>
* Allow skipping forks and mirrors from being indexed (#23187)techknowlogick2023-05-251-16/+19
| | | | | | This PR adds two new options to disable repo/code search indexing of both forks and mirrors. Related: #22842
* Improve RunMode / dev mode (#24886)wxiaoguang2023-05-251-1/+7
| | | | | | | | | | 1. non-dev mode is treated as prod mode, to protect users from accidentally running in dev mode if there is a typo in this value. 2. in dev mode, do not need to really exit if there are template errors, because the template errors could be fixed by developer soon and the templates get reloaded, help: * https://github.com/go-gitea/gitea/issues/24845#issuecomment-1557615382 3. Fine tune the mail template loading message.
* Make environment-to-ini support loading key value from file (#24832)wxiaoguang2023-05-242-0/+239
| | | | | | | | | | | | | | | Replace #19857 Close #19856 Close #10311 Close #10123 Major changes: 1. Move a lot of code from `environment-to-ini.go` to `config_env.go` to make them testable. 2. Add `__FILE` support 3. Update documents 4. Add tests
* Support changing git config through `app.ini`, use ↵wxiaoguang2023-05-232-0/+57
| | | | | | | | | | | | | | | | | | | | | `diff.algorithm=histogram` by default (#24860) Close #13454 , Close #23255, Close #14697 (and maybe more related issues) Many users have the requirement to customize the git config. This PR introduces an easy way: put the options in Gitea's app.ini `[git.config]`, then the config options will be applied to git config. And it can support more flexible default config values, eg: now `diff.algorithm=histogram` by default. According to: https://stackoverflow.com/a/32367597/4754037 , `histogram diff` is efficient and doesn't like to cause server-side problems. --------- Co-authored-by: silverwind <me@silverwind.io> Co-authored-by: KN4CK3R <admin@oldschoolhack.me> Co-authored-by: Giteabot <teabot@gitea.io>
* Add CRAN package registry (#22331)KN4CK3R2023-05-221-0/+2
| | | | | This PR adds a [CRAN](https://cran.r-project.org/) package registry. ![grafik](https://user-images.githubusercontent.com/1666336/210450039-d6fa6f77-20cd-4741-89a8-1624def267f7.png)
* Support wildcard in email domain allow/block list (#24831)wxiaoguang2023-05-222-4/+69
| | | | | | | | | | | | Replace #20257 (which is stale and incomplete) Close #20255 Major changes: * Deprecate the "WHITELIST", use "ALLOWLIST" * Add wildcard support for EMAIL_DOMAIN_ALLOWLIST/EMAIL_DOMAIN_BLOCKLIST * Update example config file and document * Improve tests
* Rewrite logger system (#24726)wxiaoguang2023-05-218-323/+688
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ## ⚠️ Breaking The `log.<mode>.<logger>` style config has been dropped. If you used it, please check the new config manual & app.example.ini to make your instance output logs as expected. Although many legacy options still work, it's encouraged to upgrade to the new options. The SMTP logger is deleted because SMTP is not suitable to collect logs. If you have manually configured Gitea log options, please confirm the logger system works as expected after upgrading. ## Description Close #12082 and maybe more log-related issues, resolve some related FIXMEs in old code (which seems unfixable before) Just like rewriting queue #24505 : make code maintainable, clear legacy bugs, and add the ability to support more writers (eg: JSON, structured log) There is a new document (with examples): `logging-config.en-us.md` This PR is safer than the queue rewriting, because it's just for logging, it won't break other logic. ## The old problems The logging system is quite old and difficult to maintain: * Unclear concepts: Logger, NamedLogger, MultiChannelledLogger, SubLogger, EventLogger, WriterLogger etc * Some code is diffuclt to konw whether it is right: `log.DelNamedLogger("console")` vs `log.DelNamedLogger(log.DEFAULT)` vs `log.DelLogger("console")` * The old system heavily depends on ini config system, it's difficult to create new logger for different purpose, and it's very fragile. * The "color" trick is difficult to use and read, many colors are unnecessary, and in the future structured log could help * It's difficult to add other log formats, eg: JSON format * The log outputer doesn't have full control of its goroutine, it's difficult to make outputer have advanced behaviors * The logs could be lost in some cases: eg: no Fatal error when using CLI. * Config options are passed by JSON, which is quite fragile. * INI package makes the KEY in `[log]` section visible in `[log.sub1]` and `[log.sub1.subA]`, this behavior is quite fragile and would cause more unclear problems, and there is no strong requirement to support `log.<mode>.<logger>` syntax. ## The new design See `logger.go` for documents. ## Screenshot <details> ![image](https://github.com/go-gitea/gitea/assets/2114189/4462d713-ba39-41f5-bb08-de912e67e1ff) ![image](https://github.com/go-gitea/gitea/assets/2114189/b188035e-f691-428b-8b2d-ff7b2199b2f9) ![image](https://github.com/go-gitea/gitea/assets/2114189/132e9745-1c3b-4e00-9e0d-15eaea495dee) </details> ## TODO * [x] add some new tests * [x] fix some tests * [x] test some sub-commands (manually ....) --------- Co-authored-by: Jason Song <i@wolfogre.com> Co-authored-by: delvh <dev.lh@web.de> Co-authored-by: Giteabot <teabot@gitea.io>
* Implement actions artifacts (#22738)FuXiaoHei2023-05-191-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Implement action artifacts server api. This change is used for supporting https://github.com/actions/upload-artifact and https://github.com/actions/download-artifact in gitea actions. It can run sample workflow from doc https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts. The api design is inspired by https://github.com/nektos/act/blob/master/pkg/artifacts/server.go and includes some changes from gitea internal structs and methods. Actions artifacts contains two parts: - Gitea server api and storage (this pr implement basic design without some complex cases supports) - Runner communicate with gitea server api (in comming) Old pr https://github.com/go-gitea/gitea/pull/22345 is outdated after actions merged. I create new pr from main branch. ![897f7694-3e0f-4f7c-bb4b-9936624ead45](https://user-images.githubusercontent.com/2142787/219382371-eb3cf810-e4e0-456b-a8ff-aecc2b1a1032.jpeg) Add artifacts list in actions workflow page.
* Fix Actions being enabled accidentally (#24802)Jason Song2023-05-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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. https://github.com/go-gitea/gitea/blob/25d4f95df25dae5226e96e813dde87b071d9155e/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.**
* Make mailer SMTP check have timed context (#24751)wxiaoguang2023-05-161-7/+9
| | | | | | | | | Make mailer SMTP check have timed context Otherwise Gitea may block for long time if the DNS request blocks. --------- Co-authored-by: Giteabot <teabot@gitea.io>
* Add Go package registry (#24687)KN4CK3R2023-05-141-0/+2
| | | | | | | Fixes #7608 This PR adds a Go package registry usable with the Go proxy protocol. ![grafik](https://github.com/go-gitea/gitea/assets/1666336/328feb5c-3df2-4f9d-8eae-fe3126d14c37)
* Improve avatar uploading / resizing / compressing, remove Fomantic card ↵wxiaoguang2023-05-131-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | module (#24653) Fixes: #8972 Fixes: #24263 And I think it also (partially) fix #24263 (no need to convert) , because users could upload any supported image format if it isn't larger than AVATAR_MAX_ORIGIN_SIZE The main idea: * if the uploaded file size is not larger than AVATAR_MAX_ORIGIN_SIZE, use the origin * if the resized size is larger than the origin, use the origin Screenshots: JPG: <details> ![image](https://github.com/go-gitea/gitea/assets/2114189/70e98bb0-ecb9-4c4e-a89f-4a37d4e37f8e) </details> APNG: <details> ![image](https://github.com/go-gitea/gitea/assets/2114189/9055135b-5e2d-4152-bd72-596fcb7c6671) ![image](https://github.com/go-gitea/gitea/assets/2114189/50364caf-f7f6-4241-a289-e485fe4cd582) </details> WebP (animated) <details> ![image](https://github.com/go-gitea/gitea/assets/2114189/f642eb85-498a-49a5-86bf-0a7b04089ae0) </details> The only exception: if a WebP image is larger than MaxOriginSize and it is animated, then current `webp` package can't decode it, so only in this case it isn't supported. IMO no need to support such case: why a user would upload a 1MB animated webp as avatar? crazy ..... --------- Co-authored-by: silverwind <me@silverwind.io>
* Add Alpine package registry (#23714)KN4CK3R2023-05-121-0/+2
| | | | | | | | | | | | | | | | | | This PR adds an Alpine package registry. You can follow [this tutorial](https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package) to build a *.apk package for testing. This functionality is similar to the Debian registry (#22854) and therefore shares some methods. I marked this PR as blocked because it should be merged after #22854. ![grafik](https://user-images.githubusercontent.com/1666336/227779595-b76163aa-eea1-4a79-9583-775c24ad74e8.png) --------- Co-authored-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: silverwind <me@silverwind.io> Co-authored-by: Giteabot <teabot@gitea.io>
* Support SSH for go get (#24664)rune2023-05-121-0/+2
| | | | | | | | | | fix #12192 Support SSH for go get --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Giteabot <teabot@gitea.io> Co-authored-by: mfk <mfk@hengwei.com.cn> Co-authored-by: silverwind <me@silverwind.io>
* Increase default LFS auth timeout from 20m to 24h (#24628)wxiaoguang2023-05-101-1/+1
| | | | | | | | | | | | | According to the discussion with DanielGibson, the default "20m" seems too short. It would make LFS fail if the file is large / network is slow. I think relaxing this timeout doesn't have side affect. So change the default value to 24h, IMO that should be long enough. ## :warning: BREAKING If admins want the previous timeout, they should set the setting `[server].LFS_HTTP_AUTH_EXPIRY`.
* Remove unnecessary code (#24610)Lunny Xiao2023-05-103-18/+6
| | | As title, remove unnecessary code.
* Rewrite queue (#24505)wxiaoguang2023-05-085-187/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | # ⚠️ Breaking Many deprecated queue config options are removed (actually, they should have been removed in 1.18/1.19). If you see the fatal message when starting Gitea: "Please update your app.ini to remove deprecated config options", please follow the error messages to remove these options from your app.ini. Example: ``` 2023/05/06 19:39:22 [E] Removed queue option: `[indexer].ISSUE_INDEXER_QUEUE_TYPE`. Use new options in `[queue.issue_indexer]` 2023/05/06 19:39:22 [E] Removed queue option: `[indexer].UPDATE_BUFFER_LEN`. Use new options in `[queue.issue_indexer]` 2023/05/06 19:39:22 [F] Please update your app.ini to remove deprecated config options ``` Many options in `[queue]` are are dropped, including: `WRAP_IF_NECESSARY`, `MAX_ATTEMPTS`, `TIMEOUT`, `WORKERS`, `BLOCK_TIMEOUT`, `BOOST_TIMEOUT`, `BOOST_WORKERS`, they can be removed from app.ini. # The problem The old queue package has some legacy problems: * complexity: I doubt few people could tell how it works. * maintainability: Too many channels and mutex/cond are mixed together, too many different structs/interfaces depends each other. * stability: due to the complexity & maintainability, sometimes there are strange bugs and difficult to debug, and some code doesn't have test (indeed some code is difficult to test because a lot of things are mixed together). * general applicability: although it is called "queue", its behavior is not a well-known queue. * scalability: it doesn't seem easy to make it work with a cluster without breaking its behaviors. It came from some very old code to "avoid breaking", however, its technical debt is too heavy now. It's a good time to introduce a better "queue" package. # The new queue package It keeps using old config and concept as much as possible. * It only contains two major kinds of concepts: * The "base queue": channel, levelqueue, redis * They have the same abstraction, the same interface, and they are tested by the same testing code. * The "WokerPoolQueue", it uses the "base queue" to provide "worker pool" function, calls the "handler" to process the data in the base queue. * The new code doesn't do "PushBack" * Think about a queue with many workers, the "PushBack" can't guarantee the order for re-queued unhandled items, so in new code it just does "normal push" * The new code doesn't do "pause/resume" * The "pause/resume" was designed to handle some handler's failure: eg: document indexer (elasticsearch) is down * If a queue is paused for long time, either the producers blocks or the new items are dropped. * The new code doesn't do such "pause/resume" trick, it's not a common queue's behavior and it doesn't help much. * If there are unhandled items, the "push" function just blocks for a few seconds and then re-queue them and retry. * The new code doesn't do "worker booster" * Gitea's queue's handlers are light functions, the cost is only the go-routine, so it doesn't make sense to "boost" them. * The new code only use "max worker number" to limit the concurrent workers. * The new "Push" never blocks forever * Instead of creating more and more blocking goroutines, return an error is more friendly to the server and to the end user. There are more details in code comments: eg: the "Flush" problem, the strange "code.index" hanging problem, the "immediate" queue problem. Almost ready for review. TODO: * [x] add some necessary comments during review * [x] add some more tests if necessary * [x] update documents and config options * [x] test max worker / active worker * [x] re-run the CI tasks to see whether any test is flaky * [x] improve the `handleOldLengthConfiguration` to provide more friendly messages * [x] fine tune default config values (eg: length?) ## Code coverage: ![image](https://user-images.githubusercontent.com/2114189/236620635-55576955-f95d-4810-b12f-879026a3afdf.png)
* Add RPM registry (#23380)KN4CK3R2023-05-051-0/+2
| | | | | | | | | | | | | | | Fixes #20751 This PR adds a RPM package registry. You can follow [this tutorial](https://opensource.com/article/18/9/how-build-rpm-packages) to build a *.rpm package for testing. This functionality is similar to the Debian registry (#22854) and therefore shares some methods. I marked this PR as blocked because it should be merged after #22854. ![grafik](https://user-images.githubusercontent.com/1666336/223806549-d8784fd9-9d79-46a2-9ae2-f038594f636a.png)
* Fix the permission of team's `Actions` unit issue (#24536)sillyguodong2023-05-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 disabled. ![image](https://user-images.githubusercontent.com/33891828/236370415-961082b2-82d2-4d9e-8025-83872ad08cbb.png) 2. `actions` is not displayed in the sidebar on the team details page ![image](https://user-images.githubusercontent.com/33891828/236371817-f39f9bc9-5926-4b88-b5e6-d93617fcfb07.png)
* Merge setting.InitXXX into one function with options (#24389)Lunny Xiao2023-05-042-54/+32
| | | | This PR will merge 3 Init functions on setting packages as 1 and introduce an options struct.
* Add Debian package registry (#24426)KN4CK3R2023-05-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Co-authored-by: @awkwardbunny This PR adds a Debian package registry. You can follow [this tutorial](https://www.baeldung.com/linux/create-debian-package) to build a *.deb package for testing. Source packages are not supported at the moment and I did not find documentation of the architecture "all" and how these packages should be treated. ![grafik](https://user-images.githubusercontent.com/1666336/218126879-eb80a866-775c-4c8e-8529-5797203a64e6.png) Part of #20751. Revised copy of #22854. --------- Co-authored-by: Brian Hong <brian@hongs.me> Co-authored-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: Giteabot <teabot@gitea.io>
* Fix incorrect CurrentUser check for docker rootless (#24441)wxiaoguang2023-04-301-8/+14
| | | | The IsRunUserMatchCurrentUser logic is fragile, the "SSH" config is not ready when it executes.
* Remove unused setting `time.FORMAT` (#24430)Yarden Shoham2023-04-291-37/+2
| | | | | | | It's loaded and then never used. --------- Co-authored-by: Giteabot <teabot@gitea.io>
* Revert "Add Debian package registry" (#24412)Yarden Shoham2023-04-281-2/+0
| | | Reverts go-gitea/gitea#22854
* Add Debian package registry (#22854)KN4CK3R2023-04-281-0/+2
| | | | | | | | | | | | | | Co-authored-by: @awkwardbunny This PR adds a Debian package registry. You can follow [this tutorial](https://www.baeldung.com/linux/create-debian-package) to build a *.deb package for testing. Source packages are not supported at the moment and I did not find documentation of the architecture "all" and how these packages should be treated. --------- Co-authored-by: Brian Hong <brian@hongs.me> Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Add .livemd as a markdown extension (#22730)contra-bit2023-04-262-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ## Needs and benefits [Livebook](https://livebook.dev/) notebooks are used for code documentation and for deep dives and note-taking in the elixir ecosystem. Rendering these in these as Markdown on frogejo has many benefits, since livemd is a subset of markdown. Some of the benefits are: - New users of elixir and livebook are scared by unformated .livemd files, but are shown what they expect - Sharing a notebook is as easy as sharing a link, no need to install the software in order to see the results. [goldmark-meraid ](https://github.com/abhinav/goldmark-mermaid) is a mermaid-js parser already included in gitea. This makes the .livemd rendering integration feature complete. With this PR class diagrams, ER Diagrams, flow charts and much more will be rendered perfectly. With the additional functionality gitea will be an ideal tool for sharing resources with fellow software engineers working in the elixir ecosystem. Allowing the git forge to be used without needing to install any software. ## Feature Description This issue requests the .livemd extension to be added as a Markdown language extension. - `.livemd` is the extension of Livebook which is an Elixir version of Jupyter Notebook. - `.livemd` is` a subset of Markdown. This would require the .livemd to be recognized as a markdown file. The Goldmark the markdown parser should handle the parsing and rendering automatically. Here is the corresponding commit for GitHub linguist: https://github.com/github/linguist/pull/5672 Here is a sample page of a livemd file: https://github.com/github/linguist/blob/master/samples/Markdown/livebook.livemd ## Screenshots The first screenshot shows how github shows the sample .livemd in the browser. The second screenshot shows how mermaid js, renders my development notebook and its corresponding ER Diagram. The source code can be found here: https://codeberg.org/lgh/Termi/src/commit/79615f74281789a1f2967b57bad0c67c356cef1f/termiNotes.livemd ## Testing I just changed the file extension from `.livemd`to `.md`and the document already renders perfectly on codeberg. Check you can it out [here](https://codeberg.org/lgh/Termi/src/branch/livemd2md/termiNotes.md) --------- Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Don't set meta `theme-color` by default (#24340)silverwind2023-04-261-1/+1
| | | | | | | | | | | 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.
* Refactor config provider (#24245)Lunny Xiao2023-04-2513-137/+212
| | | | | | | This PR introduces more abstract about `ConfigProvider` and hides more `ini` references. --------- Co-authored-by: delvh <dev.lh@web.de>
* Refactor `setting.Other` and remove unused `SHOW_FOOTER_BRANDING` (#24270)wxiaoguang2023-04-221-9/+14
| | | | | | | | | | The `SHOW_FOOTER_BRANDING` came from year 2015, and it seems nobody ever uses it. It only shows an GitHub icon which seems unrelated to Gitea, it doesn't do what document says. So, remove it. ## :warning: Breaking Users can now remove the key `[other].SHOW_FOOTER_BRANDING` from their app.ini.
* Fix incorrect CORS default values (#24206)wxiaoguang2023-04-191-2/+3
| | | | | | | | | | Document: ``` ;ALLOW_DOMAIN = * ;METHODS = GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS ``` Co-authored-by: Giteabot <teabot@gitea.io>
* Allow adding new files to an empty repo (#24164)wxiaoguang2023-04-191-3/+12
| | | ![image](https://user-images.githubusercontent.com/2114189/232561612-2bfcfd0a-fc04-47ba-965f-5d0bcea46c54.png)
* Refactor cookie (#24107)wxiaoguang2023-04-131-2/+2
| | | | | | | | | | | | Close #24062 At the beginning, I just wanted to fix the warning mentioned by #24062 But, the cookie code really doesn't look good to me, so clean up them. Complete the TODO on `SetCookie`: > TODO: Copied from gitea.com/macaron/macaron and should be improved after macaron removed.
* Correct the access log format (#24085)Gary Moon2023-04-131-1/+1
| | | | | | | | | | | The default access log format has been unnecessarily escaped, leading to spurious backslashes appearing in log lines. Additionally, the `RemoteAddr` field includes the port, which breaks most log parsers attempting to process it. I've added a call to `net.SplitHostPort()` attempting to isolate the address alone, with a fallback to the original address if it errs. Signed-off-by: Gary Moon <gary@garymoon.net>
* Use a general approach to access custom/static/builtin assets (#24022)wxiaoguang2023-04-122-0/+16
| | | | | | | | | | | | | | | | | | | The idea is to use a Layered Asset File-system (modules/assetfs/layered.go) For example: when there are 2 layers: "custom", "builtin", when access to asset "my/page.tmpl", the Layered Asset File-system will first try to use "custom" assets, if not found, then use "builtin" assets. This approach will hugely simplify a lot of code, make them testable. Other changes: * Simplify the AssetsHandlerFunc code * Simplify the `gitea embedded` sub-command code --------- Co-authored-by: Jason Song <i@wolfogre.com> Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 04:02:15 +0000